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ABSTRACT 


This  thesis  documents  the  planning,  design  and  implementation  of  a  regional 
wide-area  network  connecting  K-12  schools,  research  institutions,  libraries  and 
institutions  of  higher  education  throughout  the  Monterey  Bay  area  of  California's 
central  coast.  The  goal  of  the  network  is  to  enable  students  and  educators  to  have 
access  to  the  environmental  information  and  resources  available  regionally  via  the 
Internet,  at  speeds  which  will  encourage  interaction  and  maintain  interest.  The 
wide-area  network  design  process  presents  numerous  human  and  technical 
challenges.  These  challenges  are  further  amplified  by  the  need  to  enable  educators 
to  design  and  implement  school  local  area  networks  concurrent  with  the  wide-area 
network  solution.  The  processes  used  to  resolve  these  myriad  issues  and  the 
resulting  solutions  are  of  direct  relevance  to  the  K-12  community  as  well  as 
network  planners,  administrators  and  funding  partners. 
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I.  INTRODUCTION 


As  a  member  of  the  Initiative  for  Information  Infrastructure  and  Linkage 
Applications  (I^LA)  network  design  team  this  author  participated  in  the  design  and 
implementation  of  a  regional  network,  Monterey  BayNet.  The  network  connects 
kindergarten  through  twelfth  grade  (K-12)  students,  educators  and  research  institutions 
throughout  Monterey  and  Santa  Cruz  counties  on  the  central  California  coast. 
Internetworking  local  area  networks  (LANs)  over  such  a  widely  dispersed  geographical 
area  creates  a  Wide-Area  Network  (WAN)  and  presents  many  technical  and  human 
challenges.  Lessons  learned  in  solving  these  challenges  are  presented  here  to  assist  further 
expansion  of  Monterey  BayNet,  assist  other  K-12  schools  and  assist  other  individual 
groups  building  local  and  regional  networks. 

The  importance  and  value  of  documenting  such  efibrts  can  not  be  overemphasized. 

The  technical  issues  associated  with  developing  and  deploying  a 
national  information  infrastructure  are  far  from  resolved. ...  To  a  large  extent, 
the  National  Information  Infrastructure  [Nil]  will  be  a  transformation  and 
extension  of  today's  computing  and  communications  infrastructure  (including, 
for  example,  the  Internet,  telephone,  cable,  cellular,  data,  and  broadcast 
networks).  Trends  in  each  of  these  component  areas  are  already  bringing 
about  a  next-generation  information  infrastructure.  Yet  the  outcome  of  these 
trends  is  6r  from  certain;  the  nature  of  the  National  Information  Infrastructure 
that  will  develop  is  malleable.  Choices  will  be  made  in  industry  and 
government,  beginning  with  investments  in  the  underlying  physical 
infiustructure.  Those  choices  will  affect  and  be  affected  by  many  institutions 
and  segments  of  society.  [NRC,  94] 

This  case  study  is  presented  as  a  blueprint  of  Monterey  BayNet  design  and 
implementation  efforts.  It  is  primarily  written  for  the  K-12  technology  mentors  who  are 
interested  in  joining  or  creating  their  own  regional  network.  Lessons  learned  are  also 
applicable  to  creating  community  networks  and  internetworking  Naval  Bases.  This  work 
is  particularly  valuable  as  an  example  of  the  success  that  can  be  achieved  through  the 
collaborative  partnership  of  the  educational  community,  research  community,  commerce, 
and  government. 


1 


A. 


BACKGROUND 


In  early  1994  a  number  of  grants  were  funded  that  had  been  collaboratively 
planned  to  enable  several  independent  organizations  and  volunteer  groups  to  design  and 
implement  a  regional  wide  area  network  (WAN)  called  Monterey  BayNet.  The  initial 
Monterey  Bay  Regional  Education  Futures  (MB  ReEF)  consortium  design  effort  focused 
on  the  educational  community,  keeping  a  longer  range  vision  of  expansion  to  include 
partnership  with  commerce,  tourism,  and  agriculture.  A  three-tier  approach  was  adopted 
to  match  a  hierarchy  of  service  needs,  expertise,  and  technology.  Figure  1 . 1  shows  the 
initial  Monterey  BayNet  member  sites  as  identified  by  the  MB  ReEF  consortia  for  CalREN 
grant  funding. 

CalREN  was  created  by  Pacific  Bell  (PacBell)  in  1993  to  fund  collaborative 
projects  whose  applications  might  revolutionize  the  ways  that  individuals  and 
organizations  communicate  and  share  information  [PacBell,  94].  Projects  are  focused  in 
the  Education,  Health  Care,  Community,  Government,  and  Commercial  Business  areas. 
Projects  are  funded  for  a  maximum  of  two  years  and  connect  using  PacBell  data 
communications  technologies.  Technologies  available  include  Integrated  Services  Digital 
Network  (ISDN),  Switched  Digital  Service-56  (SDS-56),  Switched  Multimegabit  Data 
Service  (SMDS),  Frame  Relay  and  Asynchronous  Transfer  Mode  (ATM)  [PacBell,  95]. 

The  CalREN  grant  "Destination  Tomorrow:  making  connections  for  the  ultimate 
field  trip..."  requested  funding  for  Pacific  Bell  telecommunications  service  to  connect  43 
regional  test-bed  sites  [Matray,  94].  The  grant  was  awarded  14  April  1994.  Service 
installation  fees  and  connectivity  are  fully  funded  by  the  CalREN  grant  until  June  30th, 
1996.  Of  particular  interest  in  the  awarding  of  this  grant  is  that  PacBell  had  not  previously 
planned  to  deploy  Frame  Relay  service  in  the  Monterey  Bay  area  as  early  as  needed  by  the 
grant  recipiants.  The  collaborative  strength  and  technical  depth  of  the  MB  ReEF  effort 
persuaded  PacBell  to  advance  scheduled  technology  deployment  plans  in  support  of  the 
consortium  and  the  community. 
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The  ATM  backbone  pictured  in  Figure  1 . 1  is  deployed  independently  of  the 
regional  Frame  Relay  WAN  topology.  Discussion  of  ATM  technology  will  be  limited  to 
overview  material  for  comparison  with  the  Frame  Relay  technology  that  forms  the  core  of 
Monterey  BayNet.  Integrated  Services  Digital  Network  (ISDN)  connections  will 
someday  be  implemented  in  Monterey  BayNet  where  studio  quality  videoconferencing  is 
required.  A  comparison  of  ISDN  and  Frame  Relay  technology  follows  which  explains  the 
decision  of  the  PLA  network  design  team  to  choose  Frame  Relay  over  ISDN  as  the  initial 
core  technology. 

B.  MOTIVATION 

Monterey  BayNet  is  the  child  of  several  unique  parents.  The  Monterey  Bay 
Futures  Network  was  formed  by  community  leaders  in  response  to  the  pending  closure  of 
Fort  Ord.  This  group  was  interested  in  leveraging  the  regions  unique  environment-related 
resources  with  advanced  information  technology.  The  FLA  consortium  was  formed 
bringing  together  researchers,  government,  and  business  for  the  purpose  creating  a 
sustainable  regional  information  infrastructure.  Members  of  the  consortia  include 
Monterey  Bay  Aquarium  Research  Institute  (MBARI),  University  of  California  Santa 
Cruz  (UCSC),  California  State  University  Monterey  Bay  (CSUMB),  Naval  Postgraduate 
School  (NFS),  Cabrillo  College,  Pacific  Bell  (PacBell),  Lloyd  Internetworking,  Monterey 
County  Office  of  Education  (MCOE),  Santa  Cruz  County  Office  of  Education  (SCCOE), 
Monterey  Peninsula  Unified  School  District  (MPUSD)  and  others  [Bom,  95]. 

The  network  was  envisioned  as  a  community  resource  that  might  provide  full 
access  to  the  Internet  via  videoconferencing  and  hypermedia  applications  at  a  variety  of 
bandwidth  rates.  The  end  goal  is  the  creation  of  a  "collaborative  educational 
infrastracture  around  the  Monterey  Bay  Sanctuary  that  will  build  a  sustainable  base  and 
national  model  for  the  application  of  telecommunications  technology  in  environmental 
education".  [Matray,  94]  "Life-long  learning"  and  "access  to  informational  and 
instmctional  resources"  are  the  end  products  of  Monterey  BayNet,  not  technology  per  se 
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[Matray,  94],  Critical  to  the  understanding  of  this  project  is  that  the  technology  is  the 
vehicle  for  progress,  not  the  end  result.  This  thesis  describes  the  development  of  that 
vehicle,  which  hopefully  will  enable  the  shared  understanding  of  the  region's  resources. 


Three  overarching  and  interactive  elements  will  guide  the  development 
process  within  this  seasphere  of  influence:  high-speed  data 
communications  access  and  computer  technologies  are  made  available  to 
K-14,  scientific  research  communities,  and  libraries  by  business  and 
industry  partners.  Based  upon  this  access,  educators,  scientists,  engineers, 
and  technicians  can  work  collaboratively  to  sort  and  identify  relevant 
electronic  data  sources  based  on  real  world  applications  and  real  world 
interactions.  [Matray,  94] 


Technical  problems  have  technical  solutions.  The  truly  difficult  task  within  the 
consortia  lies  with  those  who  are  developing  the  regional  content.  The  content  is  the  final 
product  which  Monterey  BayNet  seeks  to  access.  In  this  light  the  consortia  quickly 
recognized  that  solutions  to  human  issues,  as  well  as  technical  ones,  were  critical  to  the 
long  term  success  of  the  network  [I^LA,  94]. 

This  problem  looks  just  like  one  facing  Naval  Bases  all  around  the  world  today. 
Local  and  regional  data  sources  desire  the  ability  to  share  data.  The  Internet  model 
provides  an  effective  low-cost  solution  which  can  be  adapted  to  meet  the  needs  of  a  Naval 
Depot,  Naval  Air  Station  or  Naval  Base. 


C.  HOW  TO  USE  THIS  THESIS 


This  thesis  follows  the  network  design  team's  decision  points  and  solution  rationale 
in  a  logical  order,  rather  than  in  a  chronological  order.  It  is  tailored  for  the  non-technical 
reader,  so  many  technical  details  are  (necessarily)  presented  in  overview.  It  is  intended  to 
serve  as  an  exemplar  for  similar  networking  efforts.  Recommendations  on  how  to  use  this 
thesis  for  different  individuals  follow. 
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1. 


Teachers  and  Students 


Teachers  and  students  can  use  this  thesis  to  better  understand  the  technology 
behind  the  Internet.  This  thesis  can  be  used  to  design  further  expansion  of  existing 
networks,  or  to  design  and  deploy  entirely  new  local  and  wide  area  networks.  Teachers 
entering  the  information  era  can  begin  to  develop  an  appreciation  of  the  magnitude  of 
Internet  resources  and  how  to  manage  them  in  the  educational  environment.  The 
document  also  provides  guidance  in  troubleshooting  and  managing  a  K-12  LAN. 

2.  Policy  Makers 

Security,  acceptable  use,  liability,  life-cycle  management  costs  and  standardization 
are  all  key  issues  which  were  faced  in  implementing  Monterey  BayNet.  This  thesis  can  be 
used  to  demonstrate  the  need  for  policy,  and  to  derive  a  starting  point  for  policy 
formulation.  Issues  faced  in  the  development  of  a  K-12  WAN  are  present  across  all 
networked  communities. 

3.  Network  Builders 

As  with  eveiy  project  of  any  scale,  some  decisions  were  made  which  proved  faulty. 
This  thesis  attempts  to  document  them  by  containing  a  great  many  lessons  learned.  It  can 
also  be  used  to  demonstrate  the  need  for  building  a  scalable  infrastructure  that  supports 
future  expansion  through  a  range  of  user  requirements.  The  document  also  can  be  used  to 
compare  the  major  strengths  and  weaknesses  of  emerging  fast  packet  technologies  such  as 
Frame  Relay,  Integrated  Services  Digital  Network  (ISDN)  and  Switched  Multimegabit 
Data  Service  (SMDS). 
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4. 


Network  Administrators 


This  thesis  clearly  demonstrates  the  need  for  early  investment  in  trained 
administrators  and  network  management.  This  thesis  is  of  particular  value  to 
administrators  who  are  building  a  new  WAN.  This  thesis  can  be  used  to  highlight  why 
there  needs  to  be  early  and  equal  emphasis  placed  on  network  management  and 
administration.  This  thesis  demonstrates  this  need  clearly  by  documenting  the  default 
management  case.  Further  study  of  these  topics  will  appear  in  Wide-Area  Network  (WAN) 
Management:  A  Case  Study  [Trepanier,  95]. 

5.  Navy  Personnel 

This  thesis  can  be  used  as  a  low-cost  model  for  LAN  and  WAN  connectivity  in  the 
Navy.  It  clearly  demonstrates  that  information  infrastructure  installation  does  not  require 
outsourcing  for  technical  proficiency  reasons.  Individual  commanders  can  perform  most 
or  all  work  required  to  connect  to  the  Internet.  This  thesis  can  also  be  used  to  identify 
existing  hardware  which  can  be  reused  to  lower  installation  costs.  In  today's  environment 
of  reduced  budgets  and  transition  toward  commercial  off-the-shelf  (COTS)  solutions,  this 
project  can  be  used  as  an  exemplar.  The  issues  involved  at  every  level  of  design  of  this 
K-12  network  have  parallels  within  network  design  at  DoD. 

D.  SUMMARY 


Monterey  BayNet  is  a  regional  WAN  designed  and  constructed  by  a  unique 
collaborative  volunteer  effort.  Monterey  BayNet  is  focused  on  the  K-12  community, 
linking  educators,  students  and  researchers  to  the  Internet  with  PacBell  Frame  Relay 
service.  This  thesis  presents  the  major  design  and  implementation  issues  faced  by  the 
network  design  team.  This  thesis  was  written  primarily  for  the  K-12  educator  but  parallels 
issues  faced  in  every  WAN  environment. 
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n.  RELATED  WORK 


The  scope  of  Monterey  BayNet  project  is  well  beyond  the  bounds  of  any  single 
thesis.  An  overview  of  this  diverse  research  effort  appears  in  "Networked  Ocean  Science 
Research  and  Education,  Monterey  Bay  California"  [Brutzman,  95],  emphasizing 
connectivity,  content,  access,  and  applications.  Many  of  the  issues  which  are  covered  in 
this  thesis  wiU  require  re-examination  as  technology  advances  and  user  needs  evolve. 
Other  related  efforts  complement  and  overlap  this  thesis.  They  include: 


•  Realizing  the  Information  Future:  The  Internet  and  Beyond  [NRC,  94]  -  Report 
of  the  National  Research  Council  (NRC)  NRENAISSANCE  Committee.  A  critical 
examination  of  architectural  and  deployment  issues  relating  to  the  creation  of  a  National 
Information  Infrastructure  (NB).  This  report  describes  past  and  recommended  future 
government  involvement  with  the  'superhighway'  initiatives  forming  the  Nil. 

•  I  LA  Net  Design  White  Paper  [I^LA,  94]  -  The  white  paper  is  the  initial  focal 
document  behind  several  Monterey  Bay  region  initiatives.  It  provides  necessary 
background  information  on  the  development  of  the  I^LA,  its  mission  and  goals.  Included 
are  an  executive  summary,  profiles  of  member  institutions,  tiger  team  profiles,  publicly 
accessible  information  resources  and  team  member  contact  information. 


•  Building  the  Future:  K-1 2  Network  Technology  Planning  Guide  -  The 
California  Department  of  Education's  statewide  networking  standards  [CDE,  94],  This 
document  was  carefully  designed  to  provide  broad  guidance  to  K-12  institutions  in  the 
deployment  of  information  technology.  The  guide  clearly  defines  the  need  for  Internet 

access  throughout  the  K-12  community  and  the  educational  benefits  that  access  will  yield 
to  teachers,  students  and  society. 
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•  The  fLA  Network:  Physical  Configuration  Team  Project  [Trepanier  et  al.,  95]  - 
A  report  created  by  a  team  of  Naval  Postgraduate  School  students  which  descnbe  the 
efforts  of  a  Tier  I  Monterey  BayNet  site  in  technology  transfer  to  Tier  II  and  III  sites.  The 
team’s  effort  is  particularly  successful  in  the  area  of  equipment  configuration  and  end-user 

training. 


•  Using  the  Multicast  Backbone  (MBone)for  Distance  Learning:  A  Case  Study 
A  master's  thesis  that  documents  the  viability  and  impact  of  distance  learning  using  the 
MBone  [Emswiler,  95].  The  case  study  documents  the  learning  points  denved  from  the 
successful  world-wide  multicast  of  the  Dr.  Richard  Hamming  course  "Learning  to  Learn." 

The  research  provided  complete  course  coverage,  world-wide,  for  a  full  academic  quarter. 
This  is  the  first  documented  attempt  of  extending  traditional  education  methods  using  the 

MBone. 

•  Wide-Area  Network  (WAN)  Management:  A  Case  Study  -  A  master's  thesis 
documenting  the  need  and  design  requirements  for  a  Monterey  BayNet  Network 
Information  Center  (NIC)  and  Network  Operations  Center  (NOC)  [Trepamer,  95]. 
Wide-Area  Network  (WAN)  Management:  A  Case  Study  will  provide  a  logical  extension 
from  this  thesis,  recommending  solutions  to  problem  areas  identified  in  Monterey  BayNet 
administration  and  management. 

Numerous  additional  books  and  on-line  resources  exist  for  connecting  to  the 
Internet.  Notable  entries  include; 

•  Entering  the  World-Wide  Web  (WWW):  A  Guide  to  Cyberspace  [Hughes,  94]. 

•  The  Web  Empowerment  Book  [Abraham,  94]. 

•  WWW  Unleashed  \DQ(x,vi:k)QT,  95]. 

•  The  Whole  Internet  [Krol,  93]. 

•  World  Link  An  Internet  Guide  for  Educators,  Parents,  and  Students  [Joseph,  95]. 
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The  Internet  Engineering  Task  Force  (IETF)  is  a  volunteer  group  that  "provides  a 
forum  for  working  groups  to  coordinate  technical  developments  of  new  protocols.  Its 
most  important  function  is  "the  development  and  selection  of  standards  within  the  Internet 
protocol  suite."  [Malkin,  94]  A  component  of  the  BETF  is  the  Internet  School 
Networking  (ISN)  working  group.  The  ISN  was  chartered  to  "address  issues  related  to 
the  connection  of  primary  and  secondary  schools  worldwide  to  the  Internet."  [Sellers,  95] 
The  group  maintains  a  general  discussion  mailing  list  isn-wg@nasa.gov.  To  subscribe  to 
the  mailing  list  send  e-mail  to  listmanager@nasa.gov  with  the  message  subscribe  isn-wg  in 
the  body  of  the  message,  leave  the  subject  line  blank.  The  group  has  issued  several  IETF 
Request  For  Comments  (RFC)  pertaining  directly  to  K-12  Internet  connectivity.  They 
include: 


•  RFC  1578  FYI  on  Questions  and  Answers:  Answers  to  Commonly  Asked 
'Primary  and  Secondary  School  Internet  User’  Questions  [Sellers,  94]. 

•  RFC  1709  K-12  Internetworking  Guidelines  [Gargano,  94]. 

•  RFC  1746  Ways  to  Define  User  Expectations  [Manning,  94]. 

On-line  information  pertaining  to  the  Monterey  BayNet  effort  can  be  found  at  the 
following  Universal  Resource  Locators  (URL): 

•  The  LLA  home  page  provides  access  to  LLA  summary  information,  proposals 
and  anonymous  ftp  server.  In  addition  it  has  many  useful  links  to  information  sources  on 
commerce,  digital  libraries,  education,  environment,  government.  National  Information 
Infi-astructure  (NO),  networking  and  telecommunications.  Available  at 

ftp://taurus.  cs.  nps.  navy.  mil/pub/iSla/iSla.  html. 

•  The  Learning  About  Monterey  Bay  (LAMBAY)  home  page  provides 
information  about  the  collaborative  education  and  research  surrounding  Monterey  Bay. 
Particular  emphasis  is  placed  upon  the  region's  diverse  habitats,  including  the  unusual 
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marine  life  of  the  deep  sea  canyon  [Atkinson,  95].  Links  are  provided  to  local  education, 
research,  libraries,  and  government  sites.  Available  at  http://lcmbay.cse.ucsc.edu/mh. 

•  The  Monterey  Bay  Regional  Education  Futures  (MBReEF)  Consortium  home 
page  provides  links  to  information  sources  throughout  the  Monterey  Bay  region.  Included 
are  links  referenced  by  region,  environment,  education,  research,  libraries,  government, 
commerce,  tourism  and  culture.  Available  at  http://www.ucsc.edu/mhay-region. 

•  The  Real-time  Environmental  Infomiation  Network  &  Analysis  System 
(REINAS)  home  page  provides  access  to  both  real-time  and  retrospective  regional  scale 
environmental  science  via  the  REINAS  distributed  database  environment.  The  REINAS 
project  is  a  cooperative  effort  of  Monterey  Bay  region  meteorological  and  oceanographic 
scientists  from  the  Baskin  Center  of  the  University  of  California  Santa  Cruz  (UCSC), 

Naval  Postgraduate  School  (NPS),  Monterey  Bay  Aquarium  Research  Institute  (MBARI), 
and  the  National  Oceanic  and  Atmospheric  Administration  Center  for  Ocean  Analysis  and 
Prediction  (NOAA/COAP).  The  REINAS  Project  is  funded  by  the  Office  of  Naval 
Research  under  a  University  of  California  Santa  Cruz  Research  Initiative  [Rosen,  95]. 
Available  at  http://csl.cse.ucsc.edu/reinas.html. 

The  amount  of  literature  related  to  Monterey  BayNet  is  considerable.  The 
Monterey  Bay  region  hosts  numerous  research  initiatives,  all  of  which  will  utilize 
Monterey  BayNet  as  a  vehicle  for  regional  information  dissemination.  From  the  K-12 
student  perspective  Monterey  BayNet  is  the  access  mechanism  which  unlocks  regional  and 
global  content.  The  references  listed  in  this  section  provide  a  generous  set  of  starting 
points  for  understanding  the  magnitude  and  scope  of  the  interrelated  Monterey  BayNet 
projects. 
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in.  PROBLEM  STATEMENT 


The  fundamental  problem  examined  in  this  thesis  is  how  to  cost-efFectively  and 
fiilly  connect  educators,  students  and  researchers  to  the  Internet.  More  specifically,  since 
a  predefined  group  of  participants  and  technologies  exist,  the  problem  is  "how  do  you 
cost-  effectively  connect  the  43  Monterey  BayNet  sites  using  PacBell  offered  services"? 

In  each  case  the  term  cost-effective  was  used  as  a  precondition  to  the  required 
connection  solution.  This  should  be  further  clarified  to  reflect  the  financial  constraints 
placed  upon  the  client  sites.  Educational  funding  in  California  schools  is  such  that  every 
effort  to  save  financial  resources,  without  affecting  upward  scalability,  must  be  exercised. 
The  final  solution  must  be  the  lowest  cost  solution  which  meets  end  user  needs.  California 
funding  for  technology  in  education  was  $2.35  per  student  in  1993,  compared  to  $153.20 
per  student  in  Connecticut  [Cradler,  1994] .  In  1994  California  was  ranked  last  among 
states  in  a  survey  of  student-to-computer  ratios  [QED,  94]. 

"What  are  the  end  user  needs?"  The  primary  end  user  in  Monterey  BayNet  is  the 
K-12  teacher  or  student.  A  method  of  determining  what  the  end  user  expects  from  an 
information  system  is  required  in  order  to  meet  those  expectations.  This  problem  is 
compounded  by  the  fact  that  present  technology  implementation  in  the  Monterey  Bay 
region's  education  system  is  so  badly  out  of  date.  End  users  cannot  be  expected  to 
accurately  express  needs  without  some  knowledge  of  available  systems.  A  baseline  set  of 
end  user  requirements  must  be  established  using  available  data  that  can  later  be  evaluated 
and  updated. 

The  main  question  is  how  to  facilitate  technology  transfer  to  individual  schools. 
The  design,  procurement  and  fielding  of  Local  Area  Network  (LAN)  technology  is 
required  in  order  to  capitalize  upon  Wide  Area  Networking  (WAN)  benefits.  The 
internetworking  of  schools  creates  a  regional  network  but  does  not  necessarily  provide 
access  to  Internet  data  and  information  outside  of  that  region.  The  next  question  then 
becomes  "how  do  you  build  local  area  networks  and  connect  them  to  form  a  wide  area 
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network  with  Internet  access?"  Again  the  single  overriding  constraint  is  educational 
finance  (taxpayer  dollars). 

Provided  that  these  questions  can  be  answered  and  implemented,  the  question  that 
immediately  follows  is  how  to  support  the  network  and  the  end  users.  An  information 
system  must  be  supported  in  order  to  remain  effective.  Network  faults  will  need  to  be 
diagnosed  and  repaired.  Users  will  require  training  and  technical  support  for  their  Local 
Area  Networks  (LANs).  Typically  solutions  are  manpower  intensive.  Where  is  the  trade¬ 
off  between  short-term  investment  costs  and  long-term  management  costs.  In  short,  "how 
do  you  ensure  that  Monterey  BayNet  will  succeed"? 

The  scope  of  the  Monterey  BayNet  project  is  so  large  that  resolution  of  many 
important  issues  has  been  delayed  in  favor  of  achieving  short-term  goals.  First  among 
these  goals  has  been  getting  schools,  teachers  and  students  on-line.  We  are  successfully 
achieving  that  goal.  This  thesis  will  answer  three  research  questions,  and  lay  the 
foundation  for  a  fourth. 

•  What  are  the  end  user  needs? 

•  How  do  you  cost-effectively  build  Local  Area  Networks  (LANs)? 

•  How  do  you  cost-effectively  connect  the  43  Monterey  BayNet  sites  using 
PacBell  services  and  Internet  access  in  a  Wide-Area  Network  (WAN)? 

•  How  do  you  ensure  that  Monterey  BayNet  will  be  sustainable? 

Follow-on  research  [Trepanier,  95]  wiU  address  wide-area  network  management  issues  in 
greater  detail. 
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IV.  SOFTWARE  APPLICATION  SELECTION 


A.  INTRODUCTION 

This  chapter  explains  the  importance  of  understanding  end  user  information  system 
requirements.  End  users  will  interact  with  the  applications  running  on  their  networks,  not 
with  the  technology  on  their  desks.  The  ULA  net  design  team  spent  time  learning  what 
the  end  user  needed,  determining  which  software  would  provide  that  functionality,  and 
finally  building  software  distributions  of  public  domain  programs  that  meet  all  user 
requirements  for  network-based  education.  Monterey  BayNet's  most  important  end  users 
are  teachers  and  students.  Monterey  BayNet  also  considers  scientific  researchers  and  the 
general  public  as  important  end  users. 


B.  END  USER  REQUIREMENTS 


A  primary  key  to  effective  system  development  and  implementation  is  the  correct 
assessment  of  end  user  requirements  [Whitten,  89].  The  net  design  team  derived  end-user 
requirements  from  needs  assessments  in  the  supporting  grant  documentation  [Matray,  94], 
and  also  from  direct  interaction  with  end  users  [Hudson,  94].  Requirements  are 
summarized  in  Figure  4. 1  and  explanations  follow. 


•  Full  Internet  access 

•  Videoconferencing  capability 

•  Hypermedia  technology:  text,  graphics,  PostScript  documents,  archived 
audio  and  video 

•  Low  cost 

•  Rapid  network  response  to  end  user  requests 


Figure  4.1  End-user  requirements. 
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Full  access  on  the  Internet  is  defined  as  "a  permanent  (full-time)  Internet 
attachment  running  Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP),  primarily 
appropriate  for  allowing  the  Internet  Community  to  access  application  servers,  operated 
by  Internet  providers"  [Crocker,  95],  TCP/IP  are  the  sets  of  software  protocols  (rules) 
which  enable  remote  computers  to  directly  connect  to  networks  which  are  interconnected 
throughout  the  Internet  [CDE,  94],  For  example.  Trumpet  Winsock  is  TCP/IP  software 
for  Windows  compliant  platforms,  and  is  freely  available  via  File  Transfer  Protocol  (FTP) 
download  frova.ftp.cica.indiana.edu  in  directory  ftp/pub/pc/win3Avinsock/twsk20b.zip. 
Winsock  shareware  requiring  a  $25  registration  fee  after  evaluation  [Tattam,  94], 
Similarly,  MacTUP  is  proprietary  TCP/IP  software  for  Macintosh  platforms.  The  easiest 
way  to  obtain  MacTCP  is  through  the  purchase  of  The  Internet  Starter  Kit  for  the 
Macintosh  (currently  $29.95)  at  many  bookstores  [Engst,  94],  MacTCP  is  also  provided 
with  the  Macintosh  operating  system  7.5. 

Videoconferencing  across  the  Internet  is  possible  using  a  number  of  differing 
applications.  The  net  design  team  is  currently  conducting  research  with  the  Multicast 
Backbone  (MBone)  which  allows  one-to-many  communications  [Macedonia,  Brutzman, 
94][Emswiler,  95].  MBone  software  is  not  yet  available  for  Windows  and  Macintosh 
platforms  but  is  expected.  An  interim  videoconferencing  tool  (also  free)  is  CU-SeeMe 
[Cogger,  94].  CU-SeeMe  allows  point-to-point  connections  between  both  Macintosh  and 
Windows  platforms. 

Interactive  technology  refers  to  World-Wide  Web  (WWW)  graphical  browsers 
such  Mosaic  [NCSA,  94]  and  Netscape  [NCC,  95].  These  tools  allow  easy  access  to 
hypertext  and  multimedia  information.  Widespread  availability  of  these  effective  and  user- 
friendly  tools  has  revolutionized  use  of  the  Internet. 

Members  of  the  net  design  team  met  to  identify  a  suite  of  publicly  available 
applications  which  would  meet  end  user  needs  in  both  the  Macintosh  and  Windows 
environment  (Appendices  A,  B).  Choosing  and  evaluating  applications  from  publicly 
available  freeware  and  shareware  ensured  that  software  cost  was  minimal.  The  final 
software  and  corresponding  functionality  reconimendations  are  shown  in  Table  4. 1 . 
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Interestingly,  these  choices  are  a  superset  of  what  is  recommended  for  National 
Information  Infrastructure  compliance  (Nil)  [NRC,  94], 


WINDOWS 

MACINTOSH 

FUNCTIONALITY 

APPLICATION 

APPLICATION 

Graphical  Web  Browser 

Netscape 

Netscape 

Mail  Client 

Eudora 

Eudora 

Usenet  Newsreader 

WinVNNNTP 

Newswatcher 

File  Transfer  Protocol  Tool 

WSJFTP 

Fetch 

Virtual  Terminal  Access 

Trmptel 

NCSA  Telnet 

Gopher 

WinGopher 

TurboGopher 

Image  viewer/converter 

Lview 

GIF  converter 

Sound  viewer 

Wham 

SoundMachine 

Video  file  viewer 

Quicktime 

Sparkle 

Data  compression  /  decompression  tool 

WinZip 

Stuffit  Expander 

Shared  whiteboard  application 

NCSA  Collage 

NCSA  Collage 

SGML  application 

HotMetal 

BBEdit 

Video  Conferencing 

CU-SeeMe 

CU-SeeMe 

Virus  Protection 

F-Prot 

Disinfectant 

Network  Diagnostics 

Ping 

MacTCP  Watcher 

PDF  file  viewer 

Adobe  Acrobat 

Adobe  Acrobat 

PostScript  file  viewer 

GhostScript 

GhostScript 

Table  4. 1 .  Software  functionality  provided  in  final  software  distribution  package. 

Rapid  network  response,  the  final  end  user  requirement,  has  two  contributing 
elements.  The  first  element  is  the  data  exchange  rate  (bandwidth)  between  the  end  user 
network  and  the  Internet  provider.  This  will  be  discussed  in  greater  detail  in  Chapter  VI. 
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The  second  element  is  the  ability  of  the  local  computer  to  process  the  data  provided  from 
the  Internet.  To  prevent  poor  performance  and  wasted  investment  the  net  design  team 
established  baseline  personal  computer  hardware  requirements  for  network  access  (Table 
4.2).  Platforms  which  do  not  meet  or  exceed  the  baseline  will  probably  not  perform  well 
enough  to  justify  the  expense  of  a  Network  Interface  Card  (NIC). 


Macintosh  Personal  Computer 

IBM  Compatible  Personal  Computer 

Operating  System  7.0  or  better 

Operating  System  Shell 

Microsoft  Windows  3.0  or  better 

Minimum  68030  processor 

Minimum  386  processor 

Minimum  8MB  RAM 

Minimum  8MB  RAM 

Minimum  250  MB  Hard  Drive 

Minimum  340  MB  Hard  Drive 

Ethernet  Capable 

Ethernet  Capable 

Monitor  -  256  color  minimum 

Monitor-  256  color  minimum 

Table  4.2.  Minimum  recommended  PC  hardware  for  K-12  schools  [Herbst,  95]. 

The  network  design  team  also  evaluated  IBM’s  OS/2  Warp  as  a  possible  operating 
system  shell  for  386-based  personal  computers  [IBM,  95].  OS/2  is  technically  superior  to 
Windows  in  a  number  of  ways.  However,  the  team  decided  to  focus  on  Windows  as  the 
default  environment  due  to  wider  use  and  familiarity  among  the  schools.  A  recommended 
area  for  future  work  is  to  build  an  (95/2-based  software  distribution  as  an  alternative  for 
schools.  A  further  alternative  yet  to  be  evaluated  is  Linux,  the  freeware  UNIX  operating 
system.  Since  OS/2  and  Linux  can  coreside  with  Windows,  further  opportunities  for 
improved  functionality  at  low  cost  are  expected. 
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C.  TECHNOLOGY  PUSH-PULL 


The  end  users  in  this  case  study  are  teachers  and  students.  They  are  being  placed 
in  the  position  of  responding  to  technology,  rather  than  guiding  the  integration  of 
technology.  Funding  to  support  connectivity  is  based  upon  a  CalREN  telecommunications 
access  grant  which  expires  in  June  1996  [Matray,  94],  To  achieve  maximum  benefit  from 
the  funding  in  a  timely  manner,  some  decisions  have  been  made  based  upon  assumptions 
that  are  not  yet  proven  in  practice.  The  "push"  has  been  to  quickly  get  the  technology  in 
the  field  so  that  we  can  use  the  connectivity  and  learn  from  our  errors.  All  of  the 
applications  selected  for  the  initial  implementation  will  be  reviewed  after  the  end  user  has 
had  the  opportunity  to  evaluate  their  effectiveness  in  the  educational  environment.  Thus 
the  "pull"  will  be  intellectual  market  forces  and  feedback  from  end  users  which  produces 
an  optimal  software  configuration.  Enabling  end  users  to  upgrade  and  improve  the 
recommended  software  build  will  make  this  process  sustainable  and  allow  continual 
improvement.  Figure  4.2  provides  definitions  of  technology  push  and  pull. 


•  Technology  Push  -  Educators  responding  to  sudden  technology  introduction. 

•  Technology  Pull  -  Educators  requesting  new  technology  based  upon  need. 


Figure  4.2  Definition  of  technology  push  and  pull. 


D.  ESTABLISHHiG  REALISTIC  END  USER  EXPECTATIONS 

The  technology  "push"  described  in  the  previous  section  has  often  created  end  user 
resistance  and  confusion.  Efforts  to  ease  the  strain  of  technology  "push"  have  focused 
primarily  on  training.  A  pilot  training  session,  "On-Ramp  to  the  Super  Efighway" 

[Davis,  94],  allowed  40  teachers  the  opportunity  to  receive  "hands-on"  training  at  the 
Naval  Postgraduate  School.  The  pilot  session  success  led  to  a  full  scale  "Virtual  Night" 
[Sanders,  95]  where  200  educators  attended  application  demonstration  sessions  and  later 
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had  the  opportunity  to  explore  the  Internet  on  their  own.  Educators  with  no  previous 
exposure  to  the  technology  needed  almost  zero  assistance  beyond  initial  login  procedures. 
These  sessions,  in  addition  to  net  design  team  software  demonstrations  on  January  20th 
and  27th  hopefully  have  contributed  to  ease  the  introduction  of  technology.  Clearly  they 
have  helped  to  clarify  end  user  expectations  and  create  end  user  demand  or  "pull."  Further 
hands-on  demonstration  events  are  planned  in  conjunction  with  the  SIGGRAPH 
conference  [Brutzman,  95]  and  other  events. 

E.  SUMMARY 

This  chapter  described  the  process  by  which  the  net  design  team  developed  the 
current  end  user  requirements  and  the  software  suite  to  match.  Installing  the  software  and 
maintaining  it  will  be  discussed  in  Chapter  VII.  End  user  needs  will  change  over  time.  A 
process  similar  to  that  discussed  in  this  chapter  will  be  required  to  recognize  and  manage 
changes  to  the  software  suite.  Additional  research  is  needed  to  determine  the  optimal  use 
of  technology  in  the  K-12  community.  The  net  design  team  has  highlighted  multi-media 
and  videoconferencing  applications.  Further  research  can  focus  the  requirements  by 
determining,  for  instance,  the  system  response  time  required  to  maintain  student  attention 
and  interaction.  It  is  strongly  recommended  that  the  effectiveness  of  the  initial  software 
load  be  evaluated  by  the  end  of  the  first  year. 

The  most  exciting  and  encouraging  aspect  of  this  entire  project  is  that  these  are  not 
merely  theoretical  problems.  Real  teachers  and  real  students  are  beginning  to  use  the 
technology  to  work  on  real  problems.  We  expect  to  learn  very  interesting  results. 
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V.  LOCAL  AREA  NETWORK  (LAN)  DESIGN 


A.  INTRODUCTION 


"What  is  a  LAN?  How  do  I  build  a  LAN?"  This  chapter  will  provide  all  of  the 
technical  and  background  information  required  to  build  a  sustainable  local  area  network. 
The  goal  is  to  design  a  LAN  which  meets  immediate  user  needs,  and  can  be  later  expanded 
as  user  needs  evolve.  There  is  a  great  deal  of  information  involved,  but  the  planning  and 
building  a  LAN  itself  is  straightforward  and  appears  in  Figure  5. 1 . 


•  Appoint  a  Network  Manager. 

•  Evaluate  existing  wire  and  cable  paths  for  possible  reuse. 

•  Make  a  site  drawing  which  shows  desired  computer  locations. 

•  Draw  network  using  topology  guidelines  in  this  chapter  and  following 
existing  cable  paths. 

•  Derive  equipment  requirements  from  the  site  plan. 

•  Procure  equipment  (Appendix  E). 

•  Install. 


Figure  5.1  Local  Area  Network  (LAN)  planning  methodology. 


B.  LOCAL  AREA  NETWORK  (LAN)  DEFINITION 

A  common  misconception  is  that  a  LAN  is  the  sharing  of  data,  whereas  in  fact  a 
LAN  is  merely  the  transmission  path  upon  which  sharing  may  occur.  The  shared  medium 
is  the  physical  infrastructure  or  cabling  which  makes  up  the  backbone  of  every  LAN.  Here 
is  one  definition; 


The  IEEE  802  LAN  is  a  shared  medium  peer-to-peer 
communications  network  that  broadcasts  information  for  all  stations  to 
receive.  The  LAN  enables  stations  to  communicate  directly  using  a 
common  physical  medium  on  a  point-to-point  basis.  The  network  is 
generally  owned,  used,  and  operated  by  a  single  organization.  [IEEE,  90a] 
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The  idea  of  a  shared  medium  is  a  key  concept  when  planning  a  LAN.  The 
infrastructure  is  the  physical  wiring  of  the  LAN,  over  which  all  network  devices 
communicate.  A  properly  designed  infrastructure  can  be  flexible  enough  to  support 
current  and  future  networking  needs.  While  cable  itself  is  relatively  inexpensive,  the  labor 
involved  in  installing  cable  or  modifying  existing  cable  runs  can  be  daunting.  Cable  and 
hardware  infrastructure  quickly  become  the  primary  limiting  factors  in  most  LANs. 

C.  IEEE  802.3  CSMA/CD:  ETHERNET 

Every  networked  device  requires  some  method  of  gaining  access  to  the  LAN 
shared  medium.  The  IEEE  802.3  Medium  Access  Control  (MAC)  method  is  Carrier 
Sense  Multiple  Access  with  Collision  Detection  (CSMA/CD).  CSMA/CD  is  a  contention 
technique  which  allows  devices  to  compete  for  medium  access.  The  CSMA/CD  function 
is  physically  performed  by  each  device's  Network  Interface  Card  (NIC),  commonly  called 
an  Ethernet  card. 

A  common  analogy  for  describing  low-level  CSMA/CD  functionality  is  that  of  a 
dinner  conversation  in  the  dark.  Each  guest  wants  to  speak  but  can  not  see  the  other 
guests.  In  order  to  communicate  a  guest  must  listen  for  silence,  and  then  start  speaking. 
This  is  analogous  to  the  carrier  sense  mode.  Multiple  Access  refers  to  the  fact  that  every 
guest  can  contend  for  transmission  time.  Occasionally  two  guests  will  start  speaking 
simultaneously  and  then  have  to  stop.  This  is  the  collision  detection  mode.  When  a 
collision  is  sensed  both  guests  will  stop  speaking,  listen  for  silence  for  an  independently 
random  time,  and  resume  talking. 

The  nature  of  the  MAC  method  requires  that  there  be  some  additional  constraints 
placed  upon  the  LAN.  To  continue  the  analogy  you  can  imagine  that  there  would  be  a 
limit  to  how  long  the  dinner  table  might  be,  or  how  many  guests  might  easily  converse. 
These  limits  are  summarized  in  Table  5.1.  Fortunately  the  specifics  of  how  devices 
interact  over  a  shared  medium  are  ordinarily  transparent  to  end  users.  Knowledge  of 
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low-level  network  fiinctionality  is  not  necessary  for  users  who  only  want  to  run  network 
applications. 


Ethernet 

Type 

Transmission 

Medium 

Data  Rate 

(Mbps) 

Maximum 

Segment 

Length  (m) 

Maximum 

Nodes  per 

Segment 

10BASE5 

Coaxial  Cable 

(.4  in  dia.) 

10 

500 

100 

10BASE2 

Coaxial  Cable 

(.25  in  dia.) 

10 

185 

30 

lOBASE-T 

Unshielded 

Twisted  Pair 

10 

100 

2 

Table  5.1.  IEEE  802.3  physical  layer  specifications  [IEEE90b]. 


10BASE5  Ethernet  (commonly  known  as  "ThickNet")  uses  standard  baseband 
coaxial  cable  as  its  shared  medium.  It  is  not  commonly  found  in  use  due  to  high 
installation  and  maintenance  cost.  ThickNet  design  guidelines  are  beyond  the  scope  of 
this  thesis.  10BASE2  Ethernet,  also  known  as  "ThinNet"  or  "Thin  Coax"  offers  many  of 
the  advantages  of  ThickNet  with  lower  cost  and  easier  installation.  Bus  topology  makes 
10BASE2  ideally  suited  for  use  in  network  backbone  applications.  10BASE2  Ethernet 
uses  .25  inch  diameter  Coax  (RG-58A/U  or  RG-58  C/U)  cable  as  the  shared  medium. 
lOBASE-T  Ethernet  uses  Unshielded  Twisted  Pair  (UTP)  wire  in  star  physical  topology  as 
the  shared  medium.  Most  existing  telephone-based  customer  premises  wiring  plants 
resemble  star  physical  topology.  Most  schools  in  Monterey  BayNet  use  lOBASE-T. 
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D.  SHARED  MEDHJM  SELECTION 


In  addition  to  the  design  restrictions  discussed  above,  the  type  of  shared  medium 
chosen  will  impose  growth  limitations  upon  the  LAN.  It  is  important  to  understand  that 
the  802.3  Ethernet  standard  enables  LAN  communications  at  data  exchange  rates  up  to 
10Mbps.  100BASE-T  is  currently  under  development  and  will  enable  data  exchange  rates 
of  up  to  100Mbps,  but  only  if  the  shared  medium  (i.e.  the  cable)  will  support  100Mbps. 
Media  transmission  rates  are  summarized  in  Table  5.2. 


Maximum 

Approximate 

Cable 

cost  per  foot 

Media 

rate  (Mbps) 

(1995  pricing) 

RG-58 

10 

$0.26 

CAT-1  UTP 

1 

$0.03 

CAT-2  UTP 

4 

$  0.05 

CAT-3  UTP 

16 

$0.10 

CAT-4  UTP 

20 

$0.16 

CAT-5  UTP 

100 

$0.18 

Table  5.2.  Cable  media  transmission  rates  and  approximate  cost. 

Category  1  and  2  UTP  are  low-data-rate  cables  which  can  not  support  802.3 
Ethernet.  Since  labor  is  the  primary  cost  in  cable  installation,  it  is  recommended  that  any 
new  cable  installations  use  category  5  UTP  for  future  growth.  Nevertheless,  there  is  rarely 
any  technical  need  to  upgrade  category  3  or  4  wiring  already  in  place.  Category  5  UTP 
upgrade  will  be  required  only  if  100Mbps  Ethernet  evolves  as  a  mature  technology  and 
user  needs  dictate  faster  LAN  transmission  rates.  Installation  of  category  5  UTP  where 
new  cabhng  is  required  allows  maximum  flexibility  for  fiiture  expected  requirements. 
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E.  SITE  EVALUATION  AND  END  USER  BUY-IN 


The  final  asset  which  must  be  considered  in  LAN  design  is  the  physical  site  itself. 

A  simple  map  or  blueprint  of  the  building  or  buildings  is  essential,  as  is  an  understanding 
of  existing  cable  paths  (conduits)  connecting  these  structures.  If  such  a  map  is  not 
available  it  will  be  necessary  to  create  one  by  tracing,  hand-over-hand,  the  cabling  in  place. 
A  detailed  discussion  of  local  building  codes  can  ordinarily  be  found  at  the  local  city 
planner's  office.  In  general  it  may  be  assumed  that  cabling  connecting  buildings  or  running 
through  an  exposed  outdoors  environment  needs  to  be  contained  in  a  conduit.  The  local 
physical  plant  engineer  or  building  manager  will  likely  be  knowledgeable  about  additional 
local  regulations. 

A  single  point  of  contact  on  site  must  be  appointed  as  the  network  manager.  This 
person  will  need  to  maintain  full  knowledge  of  the  premises  wiring  and  network 
configuration.  Initially  thisjob  will  not  require  much  time.  As  network  grows  and 
becomes  more  complex  this  may  evolve  into  a  sizable  task.  Without  a  single  individual 
who  is  interested  and  involved,  a  growing  LAN  will  quickly  be  at  the  mercy  of  paid 
consultants.  The  simple  knowledge  of  how  an  infrastructure  is  connected  can  save  many 
hours  of  consultant  fees. 

Since  the  LAN  is  going  to  be  a  part  of  the  larger  Internet  it  will  eventually  have  to 
be  connected  to  a  Wide-Area  Network  (WAN).  The  equipment  required  to  connect  to  the 
WAN  is  discussed  in  the  next  chapter.  A  logical  starting  point  for  LAN  design  is  to  begin 
at  the  service  provider's  Minimum  Point  Of  Entry  (MPOE).  This  is  the  first  telephone 
panel  inside  the  site  premises  after  the  telephone  pole.  PacBell  identifies  the  MPOE  with  a 
green  "MPOE"  tag.  Existing  telephone  services  are  already  configured  in  a  star  physical 
topology.  It  may  be  possible  to  use  existing  excess  capacity  in  the  locally  distributed 
telephone  wiring  to  service  your  LAN.  For  this  to  occur  the  following  must  be 
determined  to  be  true: 
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•  Existing  wire  is  24-gauge,  unshielded,  twisted-pair,  solid-conductor. 

Category  3  or  better. 

•  2  unused  twisted  pairs  are  available  to  each  end  location. 

•  The  twisted  pairs  are  free  of  splices. 

•  The  maximum  length  of  the  2  twisted  pairs  is  100  meters. 

Given  a  good  understanding  of  existing  physical  infrastructure,  LAN  designers  are 
able  to  determine  where  additional  cable  needs  to  be  installed.  The  next  two  sections 
contain  guidelines  for  planning  a  network  topology  to  meet  user  needs.  It  is  important  to 
plan  for  future  expansion  throughout  the  entire  facility,  not  just  to  meet  immediate  needs. 

F.  lOBASE-T  DESIGN  GUIDELINES 

lOBASE-T  network  design  is  based  upon  star  topology  (Figure  5.2).  lOBASE-T 
operates  over  2  pairs  of  wire,  one  pair  used  for  receive  data  signals  and  the  other  for 
transmit  data  signals.  The  wire  must  conform  to  EIA/TIA  Category  3  (or  greater)  wire 
specifications  and  follow  the  EIA/TIA-568B  wiring  scheme  (Appendix  C)  [EIA/TIA-568]. 

Every  UTP  segment  is  connected  to  exactly  two  nodes  and  segment  length  is 
limited  to  100m  (328ft).  The  term  "star"  comes  from  the  physical  topology  created  when 
a  number  of  nodes  are  connected  using  lOBASE-T  repeaters,  also  called  hubs  or 
concentrators  (Figure  5.3).  Hubs  allow  multiple  node  inputs  to  be  concentrated  into  a 
single  output.  Recall  that  the  Ethernet  MAC  method  is  CSMA/CD.  Thus  the  job  of  the 
hub  is  merely  to  amplify  an  incoming  signal  from  any  node  and  rebroadcast  it  to  all  other 
nodes. 

There  are  limitations  on  the  number  of  repeaters  and  cable  segments  allowed 
between  any  two  stations  on  the  network.  The  "5-4-3  Rule"  states  that  "there  may  be 
no  more  than  five  (5)  repeated  segments,  nor  more  than  four  (4)  repeaters  between  any 
two  nodes,  and  of  the  five  cable  segments,  only  three  (3)  maybe  populated" 

[IEEE,  90b].  The  term  "populated"  refers  to  a  segment  which  connects  two  hubs. 
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Figure  5.2  Conceptual  lOBASE-T  star  topology. 


Figure  5.3  Physical  lOBASE-T  star  topology. 
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Commercial  hubs  are  available  with  up  to  48  ports.  In  designing  the  LAN  ensure  that 
purchased  hubs  have  more  capacity  then  is  currently  needed.  This  will  allow  for  future 
expansion  and  greater  flexibility.  The  Ethernet  theoretical  maximum  is  1024  nodes  per 
lOBASE-T  network  [IEEE,  90b]. 

G.  10BASE2  DESIGN  GUIDELINES 

10BASE2  network  design  is  based  upon  bus  topology.  On  a  bus  or  backbone  a 
single  coaxial  cable  acts  as  the  shared  medium  for  all  nodes.  Signals  broadcast  from  a 
node  travel  in  both  directions  the  length  of  the  bus  and  can  be  received  by  all  nodes 
[Stallings,  94].  The  coaxial  cable  is  actually  composed  of  2  to  29  cable  lengths,  each  no 
shorter  then  .5m  (20in).  Cable  lengths  are  joined  at  each  node  with  male  BNC  'T' 
connectors  (Figure  5.4).  Note  that  each 'T'  connector  is  attached  directly  to  a  node's  NIC. 
By  definition  the  distance  between  each  node  and  the  bus  can  not  exceed  4cm  (the  depth 
of  the  BNC 'T'  connector)  [IEEE,  90b]. 
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Figure  5.4  BNC  "T"  connection  to  node. 

Each  fiill  segment  can  be  no  longer  then  1 85m  (606ft)  and  must  be  terminated  at 
each  far  end  with  a  50  ohm  BNC  terminator  to  provide  circuit  continuity.  Each  single 
segment  can  contain  no  more  than  30  nodes  and  2  terminators  (Figure  5.5). 
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Figure  5.5  Single  segment  10BASE2  network. 

Multiple  10BASE2  segments  can  be  joined  using  repeaters  (Figure  5.6).  The 
”5-4-3"  rule  discussed  in  the  previous  section  applies  to  10BASE2  networks  as  well.  A 
maximum  of  four  repeaters  are  allowable  creating  an  overall  maximum  10BASE2  span  of 
925m  and  150  nodes  [IEEE,  90b]. 


Figure  5.6  Two  segment  10BASE2  network. 


H.  lOBASE-T  /  10BASE2  COMPARISON 

10BASE2  network  installation  is  attractive  in  that  it  saves  the  initial  expense  of 
purchasing  multiple  hubs.  It  is  relatively  easy  to  install  and  removing  a  node  does  not 
affect  the  rest  of  the  network.  lOBASE-T  is  slightly  more  expensive  initially,  but  it  is  far 
more  expandable  and  cost-effective  in  the  long  term.  If  Category  5  UTP  wiring  is  in 
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place,  an  upgrade  from  lOBASE-T  to  100BASE-T  is  possible.  The  10BASE2 
infrastructure  cannot  be  upgraded  to  support  100Mbps  without  installing  new  cabling. 

Beyond  installation  cost  is  the  cost  of  preventive  and  corrective  maintenance.  A 
malfunctioning  node  on  a  10BASE2  bus  can  affect  all  other  devices  connected  to  the  bus. 
Troubleshooting  can  be  difficult  and  time  consuming.  The  usual  method  of  fault  isolation 
involves  disconnecting  devices  one  at  a  time  until  the  faulty  node  is  discovered.  In 
comparison,  a  lOBASE-T  network  node  which  malfunctions  is  easily  found  and  isolated 
from  the  rest  of  the  network.  Indication  lights  on  the  lOBASE-T  hubs  make  it  a  simple 
matter  to  troubleshoot  large  networks.  Appendix  D  contains  a  variety  of  example  LAN 
designs  implemented  in  the  performance  of  this  thesis. 

1.  EQUIPMENT  SELECTION 

There  are  numerous  vendors  that  sell  IEEE  802.3  Ethernet  products.  It  is 
important  to  standardize  the  equipment  used  in  a  network.  Standardization  of  Monterey 
BayNet  occurred  throughout  the  two  counties,  not  just  within  individual  schools.  This 
will  allow  all  of  the  end  users  to  become  familiar  with  the  strengths  and  oddities  of  a  single 
product,  rather  than  confuse  them  with  multiple  differences  between  platforms.  Appendix 
E  describes  the  Monterey  BayNet  equipment  recommendations.  These  recommendations 
serve  two  purposes.  They  simplify  the  management  of  the  WAN,  and  they  make 
troubleshooting  easier  for  the  individual  members  of  the  WAN. 

1.  Simple  Networit  Management  Protocol  (SNMP) 

"Intelligent"  networking  devices  are  those  devices  which  are  able  to  operate  as 
Simple  Network  Management  Protocol  (SNMP)  agents  [Case,  90].  Devices  which  can 
have  this  ability  include; 

•  Hubs 

•  Routers 
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•  Network  Interface  Cards 

•  Peripheral  Devices 

•  Channel  Service  Unit  (CSU)/Digital  Service  Unit 

SNMP  compatibility  greatly  enhances  a  network  administrator's  ability  to  monitor 
and  correct  problem  areas  within  the  LAN.  SNMP  agents  report  their  status  periodically 
and  upon  request  to  a  management  station.  The  management  station  in  turn  can  send 
orders  back  to  the  agent,  correcting  errors  detected  in  the  LAN. 

Maintenance  of  a  SNMP  management  station  is  often  beyond  the  ability  of  LAN 
managers.  That  responsibility  can  be  passed  up  to  the  WAN  manager.  If  the  WAN 
manager  acts  as  the  management  station  for  all  attached  LANs,  economies  of  scale  may  be 
achieved  which  make  overall  network  management  cost  effective  and  improve  system 
reliability.  The  additional  cost  of  SNMP  capability  is  nontrivial  but  SNMP  compatibility  is 
an  essential  component  of  LAN  design.  It  is  less  expensive  to  purchase  SNMP  capability 
"up  front"  than  to  upgrade  equipment  in  place.  These  issues  will  be  examined  in  fiirther 
detail  in  "Wide-Area  Network  (WAN)  Management:  A  Case  Study"  [Ir&pSimQt,  95].  A 
new  proposed  standard  for  SNMP  Version  2  which  extends  current  SNMP  capabilities  is 
discussed  in  RFC  1441  [Case,  93]. 

2.  Proprietary  Technology 

The  IEEE  802.3  standards  provide  minimum  technical  guidelines  which  many 
manufactures  have  been  able  to  exceed.  Some  of  these  products  allow  communication 
over  greater  distances  or  through  lower  grade  media.  These  products  may  be  useful  to 
provide  technical  solutions  for  situations  where  distance  constraints  .or  media  restrictions 
prevent  compliance  with  802.3  specifications.  Never  the  less,  the  LAN  planner  must 
avoid  deviation  from  minimum  specifications  whenever  possible.  The  purchase  of 
proprietary  non-standard  equipment  usually  creates  a  situation  where  the  LAN  manager 
limits  future  upgrade  possibilities  and  commits  to  a  sole  source  of  proprietary  hardware. 
Such  a  situation  is  extremely  undesirable. 
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3. 


LAN  Operating  Systems 


A  LAN  operating  system  is  required  if  users  desire  the  added  functionality  of  being 
able  to  share  a  single  copy  of  a  "networked"  software  application  throughout  the  LAN. 
This  makes  a  great  deal  of  sense  in  that  a  single  site  license  for  X  machines  is  normally 
cheaper  than  X  copies  of  that  software.  This  approach  also  frees  hard  drive  disk  space  on 
individual  computers,  usually  by  putting  the  single  copy  of  site-licensed  software  on  a  file 
server. 

Each  individual  computer  has  its  associated  operating  system,  ordinarily  MS-DOS 
6. 1  or  better  on  IBM  platforms,  and  System  7. 1  or  better  in  the  Macintosh  world.  A  LAN 
operating  system  is  software,  normally  resident  on  a  file  server,  which  enables  LAN  clients 
to  share  software  applications  resident  on  that  file  server  [Long,  93],  Macintosh 
AppleTalk  [Apple,  95]  znd  Microsoft  Windows  for  Workgroups  [Microsoft,  95]  are  two 
examples  of  LAN  operating  systems  which  enable  shared  applications  in  a  single  operating 
system  environment  without  the  additional  expense  of  a  dedicated  file  server.  In  a  LAN 
environment  with  mixed  operating  systems,  a  more  robust  LAN  operating  system  such  as 
Novell  Netware  will  be  required  to  enable  shared  applications  across  multiple  platforms. 
Configuration  of  Novell  Netware  or  equivalent  normally  requires  the  service  of  a  Certified 
Network  Engineer  (CNE). 

J.  LAN  DESIGN  SUMMARY 

The  focus  of  this  chapter  has  been  on  building  a  LAN  with  the  supporting 
infrastructure  to  make  it  expandable  for  future  growth.  lOBASE-T  is  the  preferred 
solution.  The  most  cost-effective  implementation  utilizes  existing  excess  telephone  lines 
reaching  to  the  classrooms.  Excess  lines  are  not  always  available  and  often  new  cable  is 
required.  The  high  dollar  item  in  cable  installation  is  the  labor  involved  in  installing  the 
cable.  The  California  Department  of  Education  (CDE)  recommends  pulling  coax  for  cable 
television  at  the  same  time  that  Category  5  UTP  is  pulled  for  the  LAN  [CDE,  94].  The 
actual  wiring  of  the  RJ-45  ports  and  8-position  modular  plugs  requires  more  patience  than 
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skill.  A  crimping  tool  and  lOBASE-T  tester  are  required  items  and  can  be  found  at  any 
major  electronics  outlet. 

Figure  5.7  outlines  some  of  the  more  common  pitfalls  encountered  on  the  way  to 
successful  implementation.  Avoid  them!  Chapter  VI  vrill  discuss  the  equipment  required 
to  connect  a  LAN  to  the  WAN.  In  LAN  design,  the  WAN  connection  is  "just  another 
node"  which  happens  to  be  at  the  MPOE.  Do  not  forget  to  include  the  WAN  connection 
in  the  site  plan. 


•  Do  not  violate  802.3  specifications  -  system  degradation  will  result  from 
crosstalk,  lost  packets  and  excess  collisions. 

•  Do  not  use  splices,  the  100  meter  rule  is  actually  expressed  in  decibel  loss. 
Splices  degrade  signal  strength. 

•  Do  not  mix  and  match  equipment,  pick  a  single  standard  product. 

•  Avoid  proprietary  solutions. 

•  Label  all  wires  and  maintain  a  detailed  record  of  the  network. 

•  Verify  that  equipment  ordered  has  the  desired  connectors.  Inexpensive  hubs 
often  require  external  transceivers  for  AUI  connections. 

•  Test  every  connection  during  and  after  installation. 

•  Verify  that  there  are  only  two  terminators  in  every  10BASE2  segment. 


Figure  5.7  Correcting  common  mistakes  in  LAN  installation. 


Many  opportunities  exist  to  continue  research  in  the  K-12  LAN  design  area.  Fiber 
Distributed  Data  Interface  (FDDI)  backbone  topology  is  becoming  increasingly  cost 
efifective  and  may  provide  a  migration  path  for  schools  with  widely  distributed  campuses. 
Another  LAN  technology  which  deserves  examination  in  the  K-12  community  is  the 
emerging  wireless  LAN.  While  still  more  expensive  than  wired  LANs,  wireless 
technology  may  provide  a  migration  path  for  schools  with  unique  needs.  Finally  the  likely 
deregulation  of  the  telecommunications  industry  may  soon  narrow  the  dividing  line 
between  telephone  provider  and  cable  television  provider.  Technology  exists  which  can 
carry  both  television  and  LAN  data  traffic  over  existing  cable  industry  coax.  As  these 
technologies  continue  to  evolve  they  need  to  be  examined  to  determine  if  they  are 
cost-efiFective  and  scalable  in  the  K-12  community. 
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VI.  WIDE  AREA  NETWORK  (WAN)  DESIGN 


This  chapter  reviews  the  telecommunications  services  available  for  WAN 
connectivity,  and  the  net  design  team's  justification  for  selection  of  Frame  Relay.  Internet 
service  provider  selection  is  discussed  briefly,  as  well  as  the  equipment  selection  and  the 
group  purchase  technique  used.  After  reviewing  the  supporting  decisions  a  coherent 
WAN  design  is  presented.  The  chapter  concludes  with  an  overview  of  the  Monterey 
BayNet  ff  addressing  schema,  autonomous  system  (AS)  registration  and  domain  name 
registration  procedures. 

A.  WAN  DESIGN  PROCESS  INTRODUCTION 


Figure  6.1  attempts  to  provide  an  ordered  view  of  WAN  design.  The  network 
design  team  experience  in  creating  Monterey  BayNet  has  shown  that  most  of  these 
decision  points  happened  almost  simultaneously.  The  decisions  are  highly  interdependent, 
making  the  designation  of  network  administrators  critical.  In  the  case  of  Monterey 
BayNet  the  network  administrators  are  the  County  Offices  of  Educations  (COEs).  The 
participating  LANs  are  43  CalREN  member  sites. 


•  Assign  Network  Administrator 

•  Identify  Participating  LANs 

•  Evaluate  and  select  communications  mode 

•  Select  Internet  provider 

•  Select  required  hardware 

•  Model  WAN  topology 

•  Assign  IP  addresses 

•  Assign  domain  names 

•  Determine  routing  and  routed  protocols 

•  Implement 


Figure  6.1  WAN  planning  steps. 
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The  following  sections  provide  background  information  and  describe  the  decisions 
of  the  network  design  team.  In  most  cases  the  network  design  team  considered  a  range  of 
options.  There  are  also  options  which  may  not  have  been  considered  or  that  this  author 
has  chosen  not  to  include.  The  success  of  the  process  at  an  individual  site  lies  in  the 
network  administrator's  careful  consideration  of  all  options  in  cooperation  with  the 
Internet  provider  and  hardware  manufacturers.  The  success  of  the  process  regionally  has 
been  due  to  the  open  and  collaborative  sharing  of  questions,  problems  and  answers. 
Individual  sites  might  have  proceeded  more  quickly  if  they  pursued  independent 
approaches,  but  it  is  highly  unlikely  that  any  uncoordinated  LANAVAN  plan  might  be 
more  reliable,  robust  and  well-suited  to  all  Monterey  BayNet  members. 

B.  TECHNOLOGY  OVERVIEW 

There  have  been  a  number  of  advances  in  computer  network  reliability  and  digital 
technology  in  the  past  decade.  These  advances  have  made  extremely  high  rates  of  data 
transfer  (bandwidth)  possible  in  a  WAN  environment.  The  net  design  team  reviewed  four 
service  options  available  through  PacBell  for  WAN  connectivity.  The  criterion  for 
selection  included  adequate  data  transfer  rates  for  hypermedia,  the  potential  to  sustain 
videoconferencing  via  MBone,  ease  of  upward  transition  when  demand  increases  in  the 
future,  and  long-term  access  costs  to  the  end  user  after  the  CalREN  grant  expires. 

1.  Asynchronous  Transfer  Mode  (ATM) 

ATM,  also  called  Cell  Relay,  is  an  ultra-high-speed  switching  and  transmission 
fabric  which  is  intended  to  form  the  high-performance  portion  of  the  Monterey  BayNet. 
The  ATM  portion  of  BayNet  will  be  distinct  from  lower-bandwidth  portions  of  BayNet 
[PLA,  94].  PacBell's  ATM  service  offering  will  initially  operate  from  45  Mbps  (DS-3 
lines)  to  155  Mbps  (OC-3  lines),  evolving  to  the  gigabit  per  second  (Gbps)  range  (billion 
bits  per  second)  [PacBell,  95].  ATM  differs  from  Frame  Relay  through  the  use  of  fixed 
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length  packets  called  cells.  The  reduction  achieved  in  individual  cell  overhead  allows 
greatly  improved  data  transmission  rates  [Stallings,  94],  A  good  introductory  reference  to 
ATM  IS  Asynchronous  Transfer  Mode  Networks:  Performance  Issues  [Onvural,  94]. 


2.  Switched  Multimegabit  Data  Service  (SMDS) 

Switched  Multimegabit  Data  Service  (SMDS)  is  a  public,  cell-switched  service 
offering  high-performance  data  transmission  [Sprague,  93].  Pacific  Bell's  current  SMDS 
offering  include  transmission  rates  from  1.5Mbps  (T1  line)  to  45Mbps  (T3  line) 

[PacBell,  95].  SMDS  differs  from  ATM  through  its  use  of  the  public  switched  network. 
The  net  design  team  did  not  recommend  the  use  of  SMDS  because  1 .5Mbps  to  45  Mbps 
connectivity  to  schools  appeared  excessive  and  expensive.  Table  6.1  lists  PacBell  tariff 
rates  for  single  LATA  SMDS  service  [PacBell,  95]. 


Data  Rate 

Installation 

HBSi 

1.17  Mbps 

$1009 

$775 

4  Mbps 

$7300 

$5700 

10  Mbps 

$7300 

$6700 

16  Mbps 

$7300 

$7200 

25  Mbps 

$7300 

$7700 

34Mbps 

$7300 

$8200 

Table  6.1.  SMDS  intra-LATA  service  tariff  [PacBell,  95] 


3.  Integrated  Services  Digital  Network  (ISDN) 

ISDN  is  a  standardized  telecommunications  network  architecture  providing 
multi-channel,  integrated  end-to-end  connectivity.  ISDN  allows  the  high-speed 
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transmission  of  digital  information  through  a  single  customer  interface,  whether  the 
content  is  voice,  data,  video  or  graphic  images  [PacBell,  95],  Basic  Rate  ISDN  (BRI) 
provides  two  full  56  Kbps  unrestricted  "B"  channels  for  voice  or  data  and  one  16  Kbps 
"D"  channel  for  signalling  and  data,  on  a  single  line.  To  the  end  user  ISDN  service  will  act 
"just  like"  telephone  service.  The  service  is  digital  so  there  is  no  need  for  a  modem,  but 
terminal  adapter  (TA)  hardware  is  required  and  "calls"  are  still  placed  linking  the  user  to 
the  target  host. 

Pacific  Bell  has  three  rate  structures  for  BRI  ISDN  service:  SDS,  Centrex,  and 
Home.  SDS  pricing  is  the  rate  structure  which  would  apply  for  most  schools  attempting  to 
connect  to  a  nearby  County  Office  of  Education  (COE).  ISDN,  like  telephone  service,  has 
usage-based  pricing  and  may  incur  long-distance  charges  depending  upon  the  location  of 
the  caller  and  destination.  Local  usage  is  charged  at  the  rate  of  $0.04  for  the  initial  call 
and  then  $0.01  for  each  minute  per  "B"  channel  [PacBell,  95].  Table  6.2  lists  the  SDS 
ISDN  charges.  The  actual  monthly  cost  of  an  ISDN  connection  may  be  highly  variable 
due  to  usage  and  long  distance  charges. 


Installation 

Monthly 

Usage  (100  Hours) 

Two  56  Kbps  "B"  Channels 

$70.75 

$24.82 

~$120  + 

Table  6.2.  PacBell  SDS  ISDN  rate.  [PacBell,  95] 


For  technical  reasons  Primary  Rate  ISDN  (PRI)  appears  to  be  the  best  ISDN 
choice  for  schools.  PRI  provides  scalable  upgrades  in  capacity  from  128  Kbps  all  the  way 
to  1.5  Mbps  (Tl)  at  64  Kbps  increments  (i.e.  "fractional  Tl").  Basic  Rate  ISDN  (BRI)  is 
unacceptable  since  the  128Kbps  bandwidth  limit  is  too  low,  and  since  BRI  equipment  is 
generally  incompatible  with  PRI  equipment. 

Long-term  use  of  ISDN  by  schools  will  require  a  predictable  and  affordable  rate 
structure  for  connectivity  charges.  Interoperability  concerns  will  hopefully  be  fixed  when 
equipment  vendors  implement  Multi-link  PPP  protocol  [Sklower  et  al.,  94],  an  open 
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standard  that  will  ensure  compatibility  and  avoid  unacceptable  proprietary  software 
restrictions.  Until  these  two  problems  are  fixed,  ISDN  is  not  a  practical  solution  for 
providing  school  connectivity.  Figure  6.2  summarizes  the  impediments  that  prevented  the 
net  design  team  from  recommending  ISDN  for  school  use; 


•  Basic  Rate  Interface  (BRI)  ISDN  is  unacceptable  due  to  low  bandwidth  with 
no  compatible  upgrade  path. 

•  Current  high  cost  of  Primary  Rate  ISDN  is  out  of  reach  for  schools. 

•  Vendor  hardware  solutions  are  proprietary  and  not  interoperable.  Multilink 
PPP  may  resolve  this,  but  has  not  been  implemented  [Sklower  et  al.,  94], 


Figure  6.2  Deficiencies  preventing  endorsement  of  ISDN  use  in  Monterey  BayNet. 


4.  Frame  Relay  Bearer  Service 

Frame  Relay  bearer  service  is  a  connection-oriented,  virtual  circuit  service. 
PacBell's  current  Frame  Relay  service  offers  transmission  rates  from  56  Kbps  to  1 .544 
Mbps,  increasing  in  56Kbps  increments  [PacBell,  95].  The  Frame  Relay  protocol  achieves 
increases  in  speed  beyond  its  predecessor  X.25  transport  protocol  by  performing  error 
correction  only  at  the  origin  and  destination  [Sprague,  93].  Frame  Relay  is  a  data  link 
layer  protocol  which  can  operate  over  ISDN  or  Frame  Relay  bearer  service,  although 
Frame  Relay  protocol  implementations  over  ISDN  are  not  currently  offered  by  Pacific  Bell 
[Chen,  89][Sprague,  93].  For  the  purposes  of  this  thesis.  Frame  Relay  will  imply  Frame 
Relay  protocol  over  Frame  Relay  bearer  service. 

Frame  Relay  is  offered  as  a  flat-rate,  distance-insensitive  service.  These  attributes 
make  Frame  Relay  an  ideal  service  for  connecting  regional  LANs,  particularly  in  the 
education  sector.  Flat-rate  pricing  (Table  6.3)  leaves  no  budgetary  doubt  for  school 
boards  in  planning  their  information  technology  budget.  Distance  insensitivity  assures  that 
there  are  no  down-stream  long-distance  charges  to  be  applied  on  top  of  the  flat  rate. 
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Data  Rate 

Installation 

Monthly 

Monthly  (2  PVC) 

56  Kbps 

$1005 

$125 

$140 

128  Kbps 

$1009 

$325 

$340 

384  Kbps 

$1009 

$575 

$590 

1.544  Mbps 

$1009 

$675 

$690 

Table  6.3.  Frame  Relay  service  flat  rate  tariff.  [PacBell,  95] 

C  SELECTION  JUSTIFICATION  FOR  FRAME  RELAY 

The  network  design  team  selected  Frame  Relay  as  the  WAN  connectivity  service 
because  it  offered  greater  access  speeds,  economy,  and  a  clear  transition  path  for 
increased  bandwidth.  The  selection  was  not  intended  to  rule  out  ISDN  usage  in  Monterey 
BayNet.  ISDN  has  some  advantages  over  Frame  Relay  in  home  dial-in  access  and  in 
studio  quality  videoconferencing.  Several  sites  are  proceeding  with  the  installation  of  both 
Frame  Relay  WAN  connectivity  and  ISDN  lines  for  comparison. 

1.  Access 

The  ability  to  use  high-bandwidth  Internet  applications  like  Netscape,  Mosaic  and 
the  MBone  tools  have  been  a  primary  driver  of  the  network  design.  Ordinarily  the 
minimum  acceptable  bandwidth  for  MBone  is  128Kbps  [Macedonia,  94].  PacBell  BRI 
ISDN  is  limited  to  1 12  Kbps  [PacBell,  95].  PacBell  Frame  Relay  services  range  from 
56Kbps  through  1.5Mbps,  making  high-bandwidth  access  feasible. 

A  second  consideration  to  the  access  equation  is  the  bandwidth  of  the  connection 
from  the  County  Office  of  Education  (COE)  to  the  Internet  provider.  Bottlenecks  can 
occur  in  a  purely  BRI  ISDN-based  WAN  because  all  lines  out  of  the  COE  can  be  the  same 
size  as  the  line  between  the  Internet  Provider  and  the  COE.  In  the  case  of  Monterey 
BayNet,  full  T-1  Frame  Relay  service  to  the  COE  greatly  reduces  the  likelihood  of 
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congestion.  The  methodology  for  designing  this  topology  will  be  presented  later  in  this 
chapter. 

2.  Economy 

At  the  site  level  ISDN  initially  seems  like  the  clear  price  leader  over  Frame  Relay. 
Equipment  costs  for  both  technologies  are  similar.  The  difference  becomes  clear  when 
usage  rates  and  long  distance  charges  are  estimated.  Frame  Relay  costs  are  time  and 
distance  insensitive.  Monthly  basic  rate  ISDN  charges,  without  long  distance  charges, 
exceed  the  128Kbps  Frame  Relay  charges  at  approximately  250  hours  of  usage.  In  a 
network  environment  250  monthly  hours  is  quite  possible,  particularly  if  the  site  wants  to 
operate  a  server  that  is  accessible  via  the  Internet  around  the  clock. 

At  the  county  level  the  economic  distinctions  are  even  clearer.  An  ISDN-based 
WAN  requires  an  ISDN  line  for  each  site  connecting  at  the  county  office.  Twenty  BRI 
lines  with  100  hours  of  average  usage  would  cost  $2896.40  monthly,  compared  to  T-1 
access  at  only  $960  per  month  ($690  per  month  +  $15  for  each  additional  DLCI)  [PacBell, 
95]. 

The  cost  of  a  router  which  can  connect  20  BRI  lines  is  significantly  greater  than 
the  cost  of  a  Frame  Relay  router  supporting  any  number  of  virtual  circuits.  Further 
savings  result  because  the  Frame  Relay-based  WAN  needs  hardware  for  only  one  physical 
WAN  connection,  compared  to  20  in  the  ISDN  topology.  The  benefit  is  greater  simplicity, 
lower  router  costs,  lower  communications  hardware  costs,  and  lower  line  costs 
[Lloyd,  94]. 

3.  Transition  to  Higher  Bandwidths 

Multiple  ISDN  B'  channels  can  be  linked  to  increase  bandwidth  using  dewces 
called  inverse  multiplexers.  "There  are  (currently)  no  good  nonproprietary  ways  to 
combine  the  two  64Kbps  bearer  (B')  chaimels  into  a  single  logical  128Kbps  channel" 
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[Lloyd,  94].  The  current  proprietary  solutions  which  do  exist  are  not  compatible  across 
manufacturers.  ISDN  Internet  providers  resolve  the  compatibility  issue  by  strictly 
specifying  the  access  hardware  which  is  known  to  work  with  their  system. 

In  contrast  to  ISDN,  Frame  Relay  hardware  specifications  are  widely  accepted  and 
interoperable  products  are  offered  by  numerous  vendors.  PacBell  supports  dedicated 
56Kbps  Frame  Relay  bearer  service  over  advanced  digital  network  (ADN)  lines. 

Fractional  T-1  lines  (128Kbps  through  1.5Mbps)  are  provided  by  High  Capacity  Digital 
Service  (HiCap).  A  T-1  line  is  composed  of  twenty  four  64Kbps  channels.  A  channel 
service  unit  (CSU)  is  used  to  aggregate  channels,  offering  a  range  of  service  from 
128Kbps  through  1 .5Mbps.  No  additional  hardware  is  required  to  increase  bandwidth 
beyond  128Kbps.  The  network  design  team  does  not  recommend  56Kbps  Frame  Relay 
service  because  it  will  not  support  nominal  MBone  transmission  rates  and  future  upgrades 
to  128Kbps  or  above  will  require  the  purchase  of  new  CSU  hardware  and  installation  of  a 
new  HiCap  line. 

D.  FRAME  RELAY  NETWORK  CONNECTION  DETAILS 

Frame  Relay  is  a  data  link  layer,  packet  switched,  multiplexed  data  networking 
technology.  The  Frame  Relay  network  is  based  upon  the  routing  of frames  (Figure  6.3) 
by  a  data  link  control  identifier  (DLCI)  value  [Stallings,  94].  Information  of  variable 
length  is  encapsulated  in  the  frame,  to  be  opened  at  the  destination.  Routing  is 
accomplished  by  forwarding  fi'ames  across  a  permanent  virtual  circuit  (PVC)  to  the 
location  specified  by  the  DLCI  connection  table.  The  table  is  maintained  and  updated  by 
the  Frame  Relay  switch.  Figure  6.4  demonstrates  how  each  site  has  a  physical  connection, 
yet  can  support  multiple  PVCs. 
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FCS 


Flag 


Figure  6.4  Example  Permanent  Virtual  Circuits  (PVCs)  in  the  Frame  Relay  cloud. 


The  Frame  Relay  multiplexing  function  enables  the  creation  of  the  multiple  PVCs. 
Each  end  of  a  PVC  is  assigned  a  unique  IP  address,  creating  the  interface  between  ff  and 
DLCI  assignment.  Each  PVC  is  assigned  a  committed  information  rate  (CIR),  i.e.  a 
"worst  case"  data  exchange  rate. 
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The  physical  equipment  needed  on  site  to  connect  a  LAN  to  a  Frame  Relay  line  is 
detailed  in  Figure  6.5.  PacBell  brings  the  High  Capacity  Digital  Service  (HiCap)  to  the 
MPOE  and  installs  the  Network  Interface  Unit  (NIU).  The  port  on  the  NIU  has  been 
disconnected  so  it  is  necessary  to  install  an  external  RJ-48  connector.  This  can  be  installed 
by  PacBell  for  a  small  charge  or  provided  and  installed  by  the  user  [PacBell,  95].  The 
RJ-48  does  not  have  to  be  physically  present  at  the  MPOE.  If  the  RJ-48  is  not  going  to  be 
installed  at  the  MPOE  then  it  is  strongly  recommended  that  PacBell  do  the  installation. 

The  demarcation  line  (also  shown  in  Figure  6.5)  is  where  PacBell's  responsibility  for 
maintenance  ends.  The  demarcation  line  is  determined  by  who  installs  the  RJ-48.  The 
physical  wiring  of  the  RJ-48  connector  to  the  output  of  the  Network  Interface  Unit  (NIU) 
is  detailed  in  Appendix  F. 


User  Respof}sibiiity 


I 


c 

la 


Minimum  Pointof  Entry  (MPOE) 


Provider  Respor}sitUity 


Site 

LAN 


Frame 
■Relay  - 
Router 


Channel 
‘Service  ‘ 


fi! 


■!RJ-4B‘ 


Unit  (CSU) 


PacBell 

Network 

Interface^ 

Unit 


PacBell 


HICAP 


V.35  Cable 
not  picwided 
with  router 


Cable 
ptwided 
with  CSU 


2  Pairs 

24AWG 

UTP 


2  Pairs 

24AWG 

UTP 


Figure  6.5  Equipment  required  to  connect  a  LAN  to  the  Frame  Relay  cloud. 


An  eight-position  modular  plug  to  eight-position  modular  plug  is  provided  with  the 
CSU  for  connection  to  the  RJ-48.  Connection  to  the  router  will  depend  upon  the  CSU 
and  router  specifications.  The  RJ-48,  CSU  and  router  must  located  together.  Both  the 
CSU  and  Router  will  require  1  lOVAC  from  a  standard  electrical  outlet.  It  is  strongly 
recommended  that  all  network  hardware  power  supplies  be  protected  with  surge 
suppression  devices.  Surge  suppression  devices  must  have  adequate  amperage  capacity 
(typically  30  to  40  amps)  and  meet  National  Electrical  Safety  Code  (NESC)  specifications 
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[ANSI,  1993],  Consideration  might  be  given  to  the  purchase  of  an  Uninterruptible  Power 
Supply  (UPS).  A  UPS  conditions  power  to  filter  out  power  spikes,  surges  and  provide 
back-up  power  in  the  event  of  a  brown-out  or  black-out.  Surge  suppressors  merely 
protect  the  internal  power  supplies  of  connected  devices  by  acting  like  an  additional  circuit 
breaker.  The  decision  to  purchase  a  UPS  is  a  business  decision,  not  a  technical  one.  A 
UPS  is  recommended  where  the  data  that  is  being  processed  has  value  exceeding  the  cost 
of  the  UPS. 

E.  INTERNET  PROVIDER  SELECTION 

Monterey  BayNet  spans  two  PacBell  Local  Access  Transport  Areas  (LATAs).  In 
this  case  the  LATA  boundaries  generally  follow  county  borders,  with  Santa  Cruz  in  LATA 
1  and  Monterey  in  LATA  8  (Figure  6.6). 


Figure  6.6  California  LATAs  [PacBell,  95]. 
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PacBell  is  a  local  telecommunications  provider.  Telecommunication  regulations 
prohibit  local  providers  from  crossing  LATA  boundaries.  Only  long  distance  providers 
such  as  AT&T,  MCI  or  Sprint  are  authorized  to  connect  local  providers  across  LATA 
boundaries.  Thus  PacBell  was  initially  prevented  from  providing  dual  LATA  service. 
Despite  this  impediment  the  CalREN  trust  agreed  to  award  a  grant  to  the  Monterey 
BayNet  consortium.  This  presented  Monterey  BayNet  with  four  options  for  connecting 
the  two  COEs. 

•  Establish  a  microwave  link  between  two  sites  spanning  the  LATA  boundary. 

•  Request  regulatory  relief  from  the  California  legislature. 

•  Hire  a  long  distance  provider  to  connect  the  COEs  across  the  LATA  boundary. 

•  Select  an  Internet  provider  which  already  has  a  inter-LATA  agreement. 

The  microwave  link  is  an  attractive  and  technically  feasible  solution  for  connecting 
data  networks.  Use  of  the  link  might  remove  the  need  to  hire  a  long  distance  provider,  but 
setup  cost  is  substantial.  A  proposal  was  discussed  at  length  with  California  Senate 
Majority  Leader  Henry  Mello  that  would  allow  PacBell  an  exemption  in  the  case  of 
Monterey  BayNet  inter-LATA  traffic.  The  legislation  was  viewed  favorably  but 
alternative  solutions  were  found  which  avoided  the  necessity  of  lengthy  legislative  effort. 
To  avoid  the  additional  expense  of  an  inter-LATA  bridge  the  network  design  team  built 
two  WANs  which  are  virtually  connected  by  the  Internet.  Internet  provider  selection  was 
thus  narrowed  to  providers  having  a  presence  in  both  LATAs  and  an  inter-LATA 
agreement  with  a  long  distance  carrier. 

The  Internet  provider  selection  process  was  based  primarily  upon  cost.  After 
much  debate  the  network  design  team  recognized  that,  reliability  issues  aside,  Internet 
access  ought  to  be  viewed  as  a  commodity.  Most  Internet  providers  offer  a  range  of 
services.  Full  service  generally  implies  that  the  provider  will  include  the  cost  of  required 
hardware  and  data  circuits  as  part  of  the  activation  and  installation  fees.  Additionally  the 
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Internet  provider  often  assigns  the  Class  C  IP  addresses  for  use  by  connected  sites  and 
provides  24-hour  network  monitoring  and  problem  resolution  to  the  site  level  [Baer,  94], 

Monterey  BayNet  opted  to  install  and  maintain  all  member  site  connections.  This 
decision  was  primarily  driven  by  cost  to  the  end  user.  WAN  management  for  each  county 
is,  by  default,  the  responsibility  of  the  respective  COE.  Each  COE  hosts  an  Internet  server 
and  functions  as  the  domain  name  server  for  the  member  sites.  This  configuration  matches 
the  recommendations  of  the  California  Department  of  Education's  Network  Technology 
Planning  Guide  [CDE,  94].  An  alternative  solution  might  have  been  the  out-sourcing  of 
installation  and  management  functions  to  an  independent  contractor  or  an  Internet 
provider.  Monterey  BayNet  further  reduced  the  cost  of  Internet  access  by  locally 
designing,  requesting  and  managing  assigned  IP  address  space  and  WAN  coimectivity 
[Trepanier,  95].  California  State  University  Network  (CSUnet)  was  contracted  as  the 
Internet  provider.  LATA  1  connectivity  in  Santa  Cruz  County  to  the  CSUnet  backbone  is 
available  through  the  Frame  Relay  cloud  to  San  Francisco  State  University  (SFSU)  and 
LATA  8  connectivity  in  Monterey  County  is  through  CSU  Monterey  Bay  (CSUMB). 
CSUnet's  long  distance  carrier  is  SprintNet,  creating  the  essential  inter-LATA  bridge 
required  to  connect  the  two  COEs. 

F.  HARDWARE  SELECTION 

The  physical  management  of  hardware  across  the  WAN  is  made  much  simpler  by 
brand-name  standardization.  Note  that  this  is  not  an  interoperability  issue  but  rather  a 
network  management  sanity  issue.  Standardization  allows  end  users  to  pool  common 
resources  and  develop  accepted  fault  isolation  patterns.  It  also  presents  the  opportunity 
for  greater  manufacturer  discounts  through  group  purchase.  Coordinating  a  group 
purchase  throughout  multiple  school  district  budgets  is  not  trivial.  The  Monterey  County 
Office  of  Education  (MCOE)  acted  as  central  agent  for  the  group  purchase  of  DSUs  and 
routers  throughout  Monterey  BayNet.  The  network  design  team  in  conjunction  with  the 
Internet  provider  (CSUnet)  played  an  advisory  role  in  equipment  selection  for  Monterey 
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BayNet.  The  equipment  selected  and  corresponding  functionality  are  described  below. 
Selection  was  based  upon  cost,  interoperability,  reliability,  reputation,  and  ease  of  use. 

1.  Channel  Service  Unit  (CSU)  Selection 

The  CSU  acts  to  synchronize  the  frames  being  output  from  the  router  with  the 
proper  channels  on  the  T-1  line.  A  T-1  line  consists  of  24  channels,  each  with  a 
bandwidth  of  64Kbps.  A  128Kbps  site  uses  channels  1  and  2,  while  a  384Kbps  site  uses 
channels  1  through  6.  The  CSU  is  configured  by  the  user  at  the  site.  Increasing 
bandwidth  requires  only  a  telephone  call  to  PacBell  to  order  the  increased  line  speed  and 
Committed  Information  Rate  (CIR).  Locally  the  only  modification  required  is  a 
corresponding  adjustment  the  CSU  hardware  settings. 

Two  different  CSUs  are  used  in  Monterey  BayNet.  Those  sites  opting  for  56Kbps 
ADN  service  install  mAdtran  56/64  digital  service  unit  (DSU).  Configuration  is 
completed  by  manipulating  switches  on  the  rear  of  the  unit.  Those  sites  installing  a  T-1 
line  will  be  using  the  Adtran  T-1  service  unit  (TSU).  Configuration  is  accomplished 
through  a  series  of  menu  selections.  Appendix  G  details  the  configuration  settings  for  both 
devices.  A  eight-position  modular  plug  to  eight-position  modular  plug  silver  satin  flat 
cable  is  provided  with  each  device  for  connection  to  the  RJ-48. 

2.  Router  Selection 

The  net  design  team  selected  the  Cisco  2500  family  of  routers  for  use  by  Monterey 
BayNet.  The  2500  series  offers  a  range  of  technology  options  to  end  user  sites.  The 
Cisco  2501  is  currently  the  low  price  leader.  A  single  LAN  router,  the  Cisco  2501  is 
capable  of  meeting  the  needs  of  most  of  our  sites.  The  Cisco  2514  provides  dual  LAN 
capacity  for  an  additional  investment  of  $350  [Cisco,  95].  The  Cisco  2514  is 
recommended  as  an  entry  level  router.  The  Cisco  2511  provides  a  single  LAN 
connection  and  16  asynchronous  ports  for  dial-in  access.  An  option  for  non-member  sites 
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in  the  BayNet  region  is  the  Cisco  25031,  an  ISDN  router  which  can  be  upgraded  to  Frame 
Relay  functionality.  The  25031  provides  a  transition  path  for  schools  outside  of  CalREN 
who  desire  to  connect  to  commercial  Internet  providers  using  free  ISDN  services  offered 
by  the  Education  First  grant  [PacBell,  94], 

A  V.35  male  to  female  34-pin  connector  is  required  to  connect  the  CSU  and  the 
router.  The  cable  is  not  provided  with  the  router.  All  Cisco  2500  routers  require  external 
transceivers  to  connect  the  LAN  to  the  router's  Attachment  Unit  Interface  (AUI)  port.  A 
sample  router  configuration  script  is  provided  in  Appendix  H. 

3.  Web  Server  Selection 

The  centralized  Internet  server  for  each  COE  is  the  Lloyd  Internetworking 
Cyberstation.  Most  servers  which  have  the  ability  to  scale  to  the  size  of  the  Monterey 
BayNet  require  UNIX  operating  system  capabilities.  The  Lloyd  Internetworking 
Cyberstation  is  a  Sun  SPARC  workstation  with  Solaris  2.3  operating  system  and  a  variety 
of  specially  configured  software  [Lloyd,  95].  It  was  selected  because  it  offers  a  graphical 
user  interface  (GUI)  over  the  operating  system  which  makes  network  administration 
possible  without  UNIX  experience.  Additional  bundled  services  include  POP2,  POP3, 
IMAP,  pine,  elm,  WWW  server,  xmosaic.  Gopher  server,  gopher  client,  FTP  server  and 
WHOIS++  server.  The  Cyberstation  acts  as  the  Domain  Name  Service  (DNS)  server, 
news  server,  mail  server  and  proxy  server  for  all  member  sites  who  require  the  service. 
This  provides  a  major  cost  savings  to  the  end  users  but  is  not  a  long  term  solution.  "A 
very  small  district  can  get  away  with  centralized  servers  and  a  medium  sized  district  can 
get  away  with  it  for  a  while,  but  ultimately  the  services  need  to  be  at  the  school"  [Lloyd, 
94].  It  is  an  excellent  way  for  new  administrators  to  learn  how  to  manage  network 
accounts.  It  is  expected  that  a  variety  of  low-cost  server  configurations  will  become 
available.  As  servers  migrate  into  schools  and  districts  hardware  and  software 
standardization  will  reduce  administrative  overhead.  This  is  a  good  area  for  future 
implementation  work. 
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G.  WAN  TOPOLOGY  DESIGN 


The  PVC  topology  evolving  from  the  decisions  of  the  network  design  team  is 
similar  to  Figure  6.7.  Frames  from  member  sites  are  transiting  the  Frame  Relay  cloud  to 
the  COE  and  then  through  the  Frame  Relay  cloud  again  to  the  Internet.  This  simple 
design  works  well  and  has  the  advantage  of  placing  the  COE  is  in  a  position  to  filter 
traffic.  It  has  the  distinct  disadvantage  of  creating  a  potential  single  point  of  failure  (i.e. 
the  COE  server).  An  alternative  design  is  allow  access  from  the  school  to  both  the  COE 
and  the  Internet  provider  directly. 


Figure  6.7  County  Office  of  Education  (COE)-centric  WAN  design  with 
a  potential  single  point  of  failure  at  the  COE. 

Figure  6.8  demonstrates  a  modified  design  that  reduces  the  traffic  navigating  the 
Frame  Relay  cloud  and  eliminates  the  single  point  of  failure.  The  loss  of  the  COE 
serverwould  not  affect  the  school's  ability  to  access  the  Internet,  nor  would  the  loss  of 
CSUnet  affect  the  ability  of  the  sites  to  communicate  with  their  respective  COE's. 

The  network  design  team  created  a  compromise  of  the  two  designs.  The  COEs 
determined  that  the  ability  of  the  COE  to  filter  inappropriate  traffic  for  the  K-8  community 
was  an  fitting  and  necessary  role.  K-8  schools  will  not  have  direct  Internet  access  PVCs. 
System  availability  was  considered  more  vital  than  proper  use  censorship  at  the  high 
school  level,  where  dual  PVCs  will  be  implemented.  The  final  PVC  topology  is  presented 
in  graphical  form  in  Appendix  I. 
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Figure  6.8  Multiple  PVC  WAN  design. 


Each  PVC  consists  of  two  IP  addresses  which  map  both  ends  of  a  DLCI.  The 
technique  for  accomplishing  this  is  called  "subnet  masking"  and  is  described  in  the  next 
section.  Figure  6.9  shows  the  map  of  DLCI  906  connecting  Monterey  High  School's 
physical  address  of 205.155.36.0  with  MCOE's  physical  address  of 205.155.43.0.  Recall 
that  the  DLCI  number  is  issued  from  PacBell  and  is  associated  with  a  CIR.  The  sum  of  all 
CIRs  is  not  allowed  to  exceed  approximately  200%  of  the  physical  line  capacity 
[Bellamy,  95].  Appendix  J  is  PacBell's  Monterey  BayNet  Frame  Relay  DLCI/CIR  matrix. 


Figure  6.9  Example  Data  Link  Control  Identifier  (DLCI)  mapping. 
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H.  DLCI  SUBNET  MASKING 


IP  addresses  are  written  in  dotted  decimal  format.  205.155.36.7  is  the  address  for 
a  single  node  at  Monterey  High.  An  IP  address  is  32  bits  in  length  and  composed  of  4 
segments.  Each  segment  of  an  address  space  is  8  bits  in  length.  In  decimal  notation  each 
8-bit  segment  equates  to  a  number  between  0  and  255.  By  convention  the  specific  values 
0  and  255  are  reserved,  leaving  1  through  254  available  for  use  in  addressing  [Lynch,  93]. 

A  Class  C  address  is  the  block  of 254  addresses  available  in  an  address  of  the 
format  W.X.  Y.O,  where  W,  X  and  Y  are  the  unique  identifier  segments  to  that  LAN. 

Every  Monterey  BayNet  site  is  issued  a  Class  C  block  as  their  physical  address  space. 
Monterey  High's  Class  C  address  is  205. 155.36.Z,  allowing  them  to  assign  up  to  254 
unique  IP  addresses  to  their  nodes  (205. 155.36. 1  through  205. 155.36.254).  Monterey 
BayNet  convention  assigns  W.X.  Y.  1  to  the  site  router,  and  W.X.  Y.2  to  the  Internet  server 
(if  present).  LAN  address  space  subnetting  is  neither  required  nor  desired.  Monterey 
BayNet's  Internet  provider  (CSUnet)  has  been  expressly  requested  that  sites  not  subnet  the 
LAN  class  C  address  blocks  assigned.  Additional  class  C  address  blocks  will  be  issued 
upon  request  if  more  that  254  nodes  are  required. 

DLCI's  are  specific  to  Frame  Relay  WANs.  DLCI's  pair  together  two  IP  addresses 
to  map  the  ends  of  the  PVC.  Rather  than  waste  hundreds  of  Class  C  addresses  a  method 
was  devised  to  subnet  a  single  Class  C  address.  255  base  10  converted  to  base  2  binary  is 
11111111.  Zero  in  binary  is  00000000.  In  subnet  masking  the  process  used  varies  the 
final  octet  to  derive  multiple  host-pairs.  Monterey  BayNet  DLCIs  use  a  subnet  mask  of 
255.255.255.252.  252  in  binary  is  11111100.  This  convention  tells  computers  that  the 
first  6  bits  of  the  final  octet  are  the  subnet  address,  and  the  final  two  bits  are  the  unique 
host.  Table  6.4  demonstrates  how  this  creates  63  unique  host-pairs  within  a  single  Class  C 
address  space,  of  which  61  are  usable  for  DLCIs.  Appendix  I  shows  all  Monterey  BayNet 
DLCI  assignments  and  the  IP  mapping  of  the  DLCIs. 
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1. 


DOMAIN  NAME  SERVICE 


Each  site  has  a  unique  physical  address  issued  from  the  block  of  Class  C  addresses 
provided  by  the  Internet  provider  [Gerich,  93],  An  alternative  method  of  obtaining  a 
block  of  addresses  is  to  request  them  directly  from  InterNIC  registration  services. 
Appendix  K  provides  the  template  for  requesting  IP  address  space  from  InterNIC. 

People  have  a  difficult  time  recalling  numbers.  205. 155.36.Z  is  not  intuitively 
recognized  as  Monterey  High  School.  Contrast  205. 1 55.36.0  with  a  domain  name  of 
mhs.monterey.kl2.ca.us.  The  casual  observer  can  presume  that  it  is  a  K-12  high  school 
acronym  from  Monterey,  California,  United  States.  This  system  of  linking  physical 
addresses  to  names  is  known  as  domain  name  service  [Postel,  94].  All  K-12  schools  are 
required  to  register  under  the  US  domain  [Copper,  93].  RFC- 1480  and  RFC- 1591 
describe  DNS  registration  and  naming  conventions.  Monterey  BayNet  and  the  net  design 
tiger  team  worked  with  the  COEs  to  develop  an  acceptable  DNS  for  member  sites.  The 
default  name  server  for  all  schools  is  the  COE  Cyberstation.  Appendix  L  is  the  DNS  for 
Monterey  BayNet.  Appendix  M  is  the  InterNIC  registration  services  DNS  registration 
template. 

J.  ROUTING  DECISIONS 

The  final  planning  event  before  connecting  LANs  to  the  WAN  is  the 
consideration  of  which  routing  protocol  to  use,  and  what  routed  protocols  to  allow. 
Routed  protocols  are  protocols  that  are  routed  through  a  network.  Internet  Protocol  (IP), 
AppleTalk,  and  NetWare  (IPX)  are  some  of  the  common  routed  protocols  operating  on 
LANs  throughout  Monterey  BayNet.  Monterey  BayNet  is  initially  allowing  only  IP  traffic 
to  be  routed  over  the  WAN.  This  decision  increases  security  by  removing  the  threat  of 
LAN  intrusion  by  outsiders.  Hackers  outside  of  Monterey  BayNet  can  not  easily  access 
information  from  Monterey  BayNet  hosts  unless  that  information  is  specifically  contained 
on  an  Internet  server.  The  decision  to  route  IP  only  also  significantly  reduces  the 
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administrative  overhead  of  managing  multiple  routed  protocols  and  eliminates  many 
possible  failure  modes. 


SUBNET 

HOST 

IP  ADDRESS 

DLCI 

COMMENT 

000000 

00 

198.189.239.0 

* 

*  By  convention  neither  host  nor  subnet 

000000 

01 

198.189.239.1 

* 

can  contain  all  zeros  or  all  ones 

000000 

10 

198.189.239.2 

* 

000000 

11 

198.189.239.3 

* 

000001 

00 

198.189.239.4 

* 

000001 

01 

198.189.239.5 

902 

This  is  the  first  unique  host  address  pair 

000001 

10 

198.189.239.6 

902 

DLCI  902  links  NPS  with  MCOE 

000001 

11 

198.189.239.7 

* 

000010 

00 

198.189.239.8 

* 

000010 

01 

198.189,239.9 

903 

This  is  the  second  unique  host  address  pair 

000010 

10 

198.189.239.10 

903 

DLCI  903  links  Seaside  with  MCOE 

000010 

11 

198.189.239.11 

* 

000011 

00 

198.189.239.12 

* 

000011 

01 

198.189.239.13 

904 

This  is  the  third  unique  host  address  pair 

000011 

10 

198.189.239.14 

904 

DLCI  904  links  MBTEC  with  MCOE 

000011 

11 

198.189.239.15 

HI 

...continues  thru  198.189.239.254 

Table  6.4.  DLCI  addressing  with  subnet  mask  255.255.255.252. 

The  routing  protocol  is  the  set  of  rules  that  the  router  uses  in  forwarding  traffic 
across  the  WAN.  Three  routing  protocols  were  considered  in  detail:  Routing  Information 
Protocol  (RIP),  Interior  Gateway  Routing  Protocol  (IGRP)  and  Open  Shortest  Path  First 
(OSPF)  .  To  ensure  interoperability  across  the  WAN  the  Internet  provider  again  played  a 
large  role  in  the  final  decision  process. 
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1. 


Routing  Information  Protocol  (RIP) 


RIP  maintains  a  set  of  routing  tables  in  each  router.  The  tables  indicate  the  path  to 
a  destination  host  and  the  "distance"  (i.e.  number  of  intermediary  routers  between  the  two 
points)  to  that  host.  RIP  maintains  only  the  shortest  route  to  a  destination.  As  the  "best" 
paths  change  the  revised  table  is  sent  as  an  update  message  to  neighboring  routers.  Each 
router  receiving  an  update  message  revises  its  tables.  On  a  limited  scale  network  RIP  is 
effective  and  easy  to  implement.  As  the  network  grows  the  tables  become  burdensome 
and  update  messages  consume  significantly  greater  bandwidth  [Stallings,  94].  RIP  is  an 
old  protocol  and  its  use  is  considered  detrimental  by  many  Internet  experts. 

2.  Interior  Gateway  Routing  Protocol  (IGRP) 

IGRP  is  a  distance  vector  interior-gateway  protocol  (IGP).  IGPs  use  an 
Autonomous  System  number  (AS)  to  identify  members  of  a  unique  WAN.  Distance 
vector  routing  protocols  call  for  each  router  to  send  all  or  a  portion  of  its  routing  table  in 
a  routing  update  message  at  regular  intervals  to  each  of  its  neighboring  routers  in  the 
network  [Stallings,  94].  As  routing  information  proliferates  through  the  network,  routers 
can  calculate  distances  to  all  nodes  within  the  AS. 

3.  Open  Shortest  Path  First  (OSPF) 

OSPF  is  a  open  standard  link-state  routing  protocol  [Moy,  94]  based  on  the 
Shortest  Path  First  (SPF)  algorithm  [Dijkstra,  59].  OSPF  sends  link-state  advertisements 
(LSAs)  to  all  other  routers  within  the  same  AS.  As  OSPF  routers  accumulate  link  state 
information,  they  use  the  SPF  algorithm  to  calculate  the  shortest  path  to  each  node 
[Stallings,  94], 
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4. 


Selection  and  Implications 


OSPF  was  initially  targeted  as  the  routing  protocol  for  Monterey  BayNet  because 
it  can  provide  the  most  effective  use  of  bandwidth.  However,  difBculty  implementing 
OSPF  on  the  Cisco  routers  during  configuration  training  caused  a  reversal  of  policy. 

An  earlier  recommendation  fi'om  CSUnet  was  to  use  OSPF  within 
our  network.  However,  the  Cisco  engineers  found  some  ugly  side-effects 
in  Cisco's  implementation  of  OSPF  and  Frame  Relay  that  would  increase 
the  complexity  of  the  addressing  in  our  network.  CSUnet  now 
recommends,  with  Cisco's  concurrence,  that  we  use  IGRP  within  the 
Monterey  BayNet.  [Taylor,  95] 

Two  final  configuration  parameters  were  established.  The  Logical  Management 
Interface  (LMI)  defines  the  protocol  for  communication  between  a  Frame  Relay  switch 
and  a  specific  router  interface.  Monterey  BayNet  adopted  the  use  of  ANSI  Logical 
Management  Interface,  standard  T1.617  Annex  D. 

The  Cisco  implementation  of  IGRP  requires  the  use  of  an  AS  number  [Cisco,  95]. 
"Registering  for  an  Autonomous  System  Number  implies  that  you  plan  to  implement  one 
or  more  gateways  and  use  them  to  connect  networks  in  the  Internet."  [InterNIC,  94]  A 
gateway  is  a  method  of  connecting  other  WANs  via  the  Monterey  BayNet  host 
[Sprague,  93].  Monterey  BayNet  does  not  currently  operate  any  WAN  gateways.  To 
fulfill  the  requirement  for  an  AS  in  the  Cisco  routers  Monterey  BayNet  arbitrarily  assigned 
the  AS  number  10  in  Santa  Cruz,  and  1 1  in  Monterey.  Using  an  unregistered  AS  number 
will  not  cause  problems  since  AS  numbers,  unlike  their  IP  number  counterparts,  are 
transparent  to  end  systems.  Excerpts  from  the  InterNIC  AS  registration  template  are 
provided  for  reference  in  Appendix  N.  The  current  version  of  the  template  is  maintained 
at  ftp://rs.  intemic.net/templates/asn-template.  txt. 
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K.  WAN  DESIGN  PROCESS  SUMMARY 


To  the  non-technical  observer  the  task  of  designing  a  WAN  seems  overwhelming. 
Monterey  BayNet  was  successfully  designed  by  the  cooperative  pooling  of  knowledge, 
experience  and  needs.  Few  members  in  the  network  design  team  had  extensive  network 
backgrounds.  None  had  the  breadth  of  knowledge  needed  to  answer  all  questions,  nor 
was  any  such  person  ever  located.  All  had  the  desire  and  drive  to  ask  all  the  right 
questions  and  search  for  the  right  answers.  This  team  process  has  been  a  critical 
component  in  successfully  identifying  and  overcoming  the  many  hurdles  involved  in 
designing  and  implementing  LANs  and  WANs  . 

Following  the  model  outlined  at  the  start  of  this  chapter  (Figure  6.1)  the  network 
design  team  selected  Frame  Relay  bearer  service  as  its  communications  mode.  It  received 
multiple  bids  for  Internet  access  and  selected  CSUnet  as  the  Internet  provider.  Working  in 
cooperation  with  CSUnet  and  PacBell  the  network  design  team  selected  the  WAN 
hardware  and  initiated  group  purchases  to  maximize  savings. 

With  the  above  decisions  the  creation  of  a  model  topology  was  relatively  simple. 
The  topology  models  demonstrated  strengths  and  weaknesses  which  were  evaluated  and 
capitalized  upon.  BP  addresses  were  assigned  to  PacBell's  DLCIs  based  upon  the  topology 
created,  and  a  workable  CIR  matrix  was  agreed  upon  with  PacBell.  Unique  site  BP 
addresses  were  assigned  and  linked  to  domdn  names  registered  within  the  US  domain 
name  system.  Finally  the  routing  and  routed  protocols  were  evaluated  and  agreed  upon, 
creating  the  need  for  additional  registration  of  two  autonomous  system  numbers. 

Monterey  BayNet  as  designed  above  has  created  a  simple-to-implement,  reliable 
regional  network.  There  has  been  no  opportunity  yet  to  evaluate  the  design  following 
implementation.  To  date  it  has  met  all  expectations.  Undoubtedly  there  are  bound  to  be 
numerous  nuances  which  were  not  considered  or  not  anticipated.  Traffic  patterns  will  be 
analyzed  to  verify  the  design  topology.  At  some  point  the  inter-LATA  issue  may  have  to 
be  re-addressed.  Much  of  the  work  of  network  management  and  administration  has  only 
just  begun,  even  as  expansion  plans  are  surfacing.  Persistence  and  perseverance  helped  us 
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find  technical  solutions  for  all  technical  problems  and  people  solutions  for  all  people 
problems.  The  same  collaborative  spirit  which  designed  Monterey  BayNet  will  continue 
to  shape  its  evolution. 
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Vn.  IMPLEMENTATION  RESULTS 


A.  IMPLEMENTATION  INTRODUCTION 

On  March  24,  1995  Seaside  High  School  became  the  first  Monterey  BayNet  site 
on-line.  To  date  25  of  43  sites  are  on-line  and  installation  efforts  continue.  May  12,  1995 
marked  the  next  milestone  with  the  first  point-to-point  videoconference  between  two  sites 
using  CU-SeeMe  [Herbst,  95][Cogger,  95]. 

The  implementation  phase  began  concurrently  with  the  design  phases.  Configuration 
"tiger"  teams  fi'om  Cabrillo  College  and  the  Naval  Postgraduate  School  began  conducting 
site  inspections  in  November  1994  [Bigelow,  94].  The  net  design  team  recognized  that  the 
end  users  understanding  of  their  role  was  critical  to  success.  Implementation  has  been 
conducted  in  three  steps. 

1)  Initial  site  inspection  with  PacBell  and  configuration  team. 

2)  Informal  follow-up  of  on-site  technical,  timing  and  procurement  issues. 

3)  PacBell  Frame  Relay  installation  and  tiger  team  configuration. 

This  chapter  will  highlight  the  configuration  team's  implementation  process  and  the  issues 
faced  at  the  site  and  WAN  management  levels. 

B.  INITIAL  SITE  INSPECTIONS 

Initial  site  inspections  called  "walk-throughs"  proved  to  be  of  critical  importance  in 
the  implementation  of  Monterey  BayNet.  The  format  was  a  scheduled  meeting  between  site 
personnel,  PacBell  Frame  Relay  installers,  and  configuration  team  personnel.  In  most  cases 
this  was  the  first  opportunity  for  end  users  to  ask  technical  questions  and  begin  to 
understand  their  roles  and  responsibilities. 

The  first  task  in  the  walk-through  process  is  for  PacBell  to  establish  the  location  of 
the  MPOE  and  verify  that  sufficient  lines  are  present  to  the  MPOE  for  Frame  Relay 
installation.  California  schools  are  generally  over  twenty  years  old  and  the  MPOE  is  not 
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always  obvious.  In  one  case  it  was  in  an  building  no  longer  used  by  the  school,  on  the  other 
side  of  the  football  field.  If  the  MPOE  is  not  in  a  position  close  to  where  router  will  be 
installed,  it  is  recommended  that  PacBell  be  consulted  on  establishing  a  secondary  MPOE  or 
extending  the  NIU  to  the  router  location.  The  location  where  the  router  and  CSU/DSU  will 
be  installed  will  require  sufficient  space  for  either  wall  mounting  of  the  devices,  or 
installation  of  a  shelf  where  the  devices  can  sit.  The  Cisco  routers  come  with  brackets 
which  allow  them  to  be  easily  mounted  flat  on  the  wall.  If  a  shelf  is  used  ensure  that  a  strap 
is  attached  to  secure  the  devices  to  the  shelf  The  location  will  also  a  require  1  lOVAC 
surge  protected  power  supply  for  both  the  router  and  CSU/DSU. 

The  next  task  of  the  walk-through  inspection  is  discussion  of  the  LAN  design 
guidelines  contained  in  Chapter  V.  The  goal  is  not  to  design  a  LAN  for  the  end  user,  but  to 
enable  the  end  user  to  consider  LAN  design  options  and  to  make  an  educated  business 
decision  at  a  later  date.  An  equipment  recommendation  list  is  critical  at  this  point  to  assist 
end  users  in  understanding  the  financial  impact  of  design  options.  The  most  frequently 
asked  question  during  a  walk-through  is  "how  much  does  it  cost."  Of  greater  importance  is 
communicating  the  need  to  invest  up-firont  in  an  inJfrastructure  which  will  meet  today's 
needs  while  remaining  scalable  in  the  future. 

A  walk-through  situation  to  avoid  is  one  where  a  LAN  already  exists,  and  the 
maintainer  of  that  LAN  is  not  present  at  the  brief  In  the  K-12  educational  sector  it  is  not 
unusual  for  technology  to  be  viewed  as  a  display  tool  for  casual  use,  rather  than  as  an 
information  resource  which  must  be  managed.  In  several  walk-throughs  end  users  expected 
the  configuration  team  to  have  perfect  knowledge  of  their  network  from  the  examination  of 
a  single  terminal.  Insist  on  the  presence  of  the  network  administrator  or  consultant  who 
maintains  the  system. 

The  final  task  of  the  walk-through  is  to  ensure  that  the  end  users  understand  the 
installation  schedule  and  what  roles  PacBell,  the  configuration  team  and  end  user  play.  It 
must  be  clearly  understood  that  PacBell  will  not  install  past  the  MPOE  without  prior 
agreement,  and  that  PacBell's  responsibility  ends  at  the  NIU  (or  at  the  RJ-48  if  installed  by 
PacBell).  The  end  user  is  responsible  for  procurement  of  all  equipment  after  the  NIU, 
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especially  the  installation  of  all  LAN  hardware  and  wiring  (if  required).  The  configuration 
team's  role  is  to  assist  in  the  configuration  of  WAN  devices  and  software  applications. 

C.  WAN  EQUIPMENT  INSTALLATION  AND  CONFIGURATION 

The  amount  of  information  presented  at  the  walk-through  is  substantial.  On  average 
the  discussions  lasted  between  two  and  three  hours.  Many  requests  for  further  information 
and  clarification  were  received  by  the  COEs  and  the  configuration  teams.  In  February  a 
Frame  Relay  service  "roll-out"  schedule  (included  in  the  CIR  matrix,  Appendix  J)  was 
created  by  PacBell  and  the  COEs.  The  roll-out  was  based  upon  the  results  of  the  walk¬ 
throughs  completed  and  end-user  requests.  It  is  interesting  that  certain  sites  were  already 
emerging  as  leaders  in  technology  implementation.  Without  exception  these  sites  had  one 
or  more  champions  who  were  willing  to  invest  personal  time  integrating  the  technology 
successfully  into  their  school  [Gwinn,  94]. 

Figure  7. 1  is  a  configuration  team  installation  checklist.  The  checklist  shows  a 
logical  progression  through  the  configuration  process.  Many  of  the  tasks  can  be  performed 
simultaneously  with  multiple  installers.  The  key  learning  points  for  the  end  user  are  the 
troubleshooting  methods  and  corrective  actions  in  the  case  of  a  suspected  WAN  error,  and 
the  functionality  of  the  software  applications  installed  on  the  computers.  Training  issues 
will  be  discussed  in  greater  detail  later  in  this  chapter. 

During  the  configuration  of  the  Cisco  routers  is  was  discovered  that  Cisco  operating 
system  version  10.2  or  greater  was  required  in  order  to  implement  the  sub-interfaces  for 
multiple  point-to-point  PVCs.  Some  of  the  routers  were  shipped  with  version  10.0  and  had 
to  be  updated.  The  procedure  for  updating  is  contained  in  the  Cisco  support  documentation 
chapter  titled  "Upgrading Run-From-Flash  Software  Images  in  the  Cisco  2500" 

[Cisco,  95]. 
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•  Configure  TSU/DSU  and  router  (Appendix  G,  H).  Verify  proper  operation 
prior  to  installation. 

•  Verify  PacBell  and  LAN  installation  complete  prior  to  installation. 

•  Install  router,  TSU/DSU,  and  RJ-48  (if  necessary  -  Appendix  F).  Verify 
adequate  ventilation  and  power  supply  are  available. 

•  Verify  connectivity  from  the  router  through  the  fi’ame  relay  cloud  to  another 
router. 

•  Install  proper  transceiver  (lOBASE-T  or  10BASE2)  and  connect  LAN  to 
router. 

•  Instruct  end  users  in  the  meaning  of  the  router,  transceiver,  and  CSU/DSU 
indication  lights.  Discuss  corrective  actions  and  points  of  contact. 

•  Verify  all  router  and  TSU/DSU  documentation  is  presented  to  the  end  user. 

•  Instruct  end  users  in  Class  C  IP  address  management.  Assist  them  in  starting 
a  log  of  address  assignments. 

•  Install  TCP  packet  drivers  at  each  LAN  terminal  (Appendix  O,  P). 

•  Install  applications  on  each  terminal.  Explain  Eudora  mail  program  setup. 
Explain  the  cautions  associated  with  CU-SeeMe  use  in  Monterey  BayNet. 

•  Test  and  demonstrate  applications. 

Figure  7.1  Configuration  Team  Installation  Checklist. 

With  the  TSU  (or  DSU  for  56  Kbps  sites)  and  router  configured  and  energized  but 
not  connected,  the  TSU  will  show  green  "PWR",  "TD"  and  "RD"  LEDs  as  well  as  a  red 
"ALM"  indication  showing  that  Frame  Relay  service  has  been  interrupted.  Connecting  the 
TSU  "Network"  port  to  the  RJ-48  with  the  provided  silver  satin  cable  should  clear  the 
alarm  indication.  If  this  is  not  the  case  then  there  is  a  problem  in  the  TSU,  a  wiring  problem 
exists,  or  the  Frame  Relay  signal  has  been  lost.  Troubleshoot  in  that  order.  Verify  the  TSU 
operation  with  a  self-test.  Verify  the  silver  satin  cable  connectivity  end-to-end  on  each  pin. 
Verify  RJ-48  wiring  as  per  Appendix  F.  Finally  contact  the  PacBell  Network  Operations 
Center  at  1-800-870-9007.  Have  the  circuit  identification  (written  on  the  PacBell  NIU)  and 
a  call-back  telephone  number  ready. 

The  router  is  connected  to  the  TSU  with  the  V.35  cable  described  in  Chapter  VI. 
This  final  connection  should  illuminate  the  remaining  two  LEDs  "RTS"  and  "CTS".  If  this 
is  not  the  case  then  there  is  a  problem  with  either  the  router  configuration  or  the  V.35  cable. 
Troubleshoot  them  in  that  order.  With  all  five  of  the  green  LEDs  illuminated,  no  alarms. 
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the  router  can  be  used  to  verify  WAN  connectivity  with  a  "ping"  check  to  the  COE 
(205.155.8.1  and  205.155.43.1  in  Santa  Cruz  and  Monterey  respectively). 

At  this  point  the  WAN  connection  is  completed.  Ensure  all  documentation  is 
consolidated  and  presented  to  the  site's  network  administrator.  Finally  verify  the  LAN 
connection  to  the  transceiver  on  router's  Ethernet  port.  The  remainder  of  the  configuration 
will  be  conducted  at  each  individual  computer  which  desires  access  to  the  WAN. 

D.  LAN  CONFIGURATION  AND  APPLICATION  INSTALLATION 

Each  site  has  a  class  C  address  space  assigned.  It  is  the  responsibility  of  the  site 
network  administrator  to  manage  this  block  of  addresses.  Monterey  BayNet  convention 
assigns  205. 155.Y.  1  to  the  router,  205. 155.Y.2  is  reserved  for  the  site's  (future)  Web 
server.  The  remainder  of  the  addresses  (205. 1 55.  Y.3  through  205. 1 55.  Y.254)  will  be 
assigned  to  devices  sequentially  by  the  network  administrator.  Maintain  an  accurate  log  of 
address  assignments.  Label  each  device  with  the  address  to  avoid  confusion. 

MacTCP  and  Trumpet  Winsock  are  the  respective  software  packet  drivers  for 
Macintosh  and  Windows  platforms.  Each  device  that  will  have  WAN  access  will  need  a 
packet  driver  installed  and  manually  configured  with  the  device's  assigned  IP  address. 
Appendices  O  and  P  describe  the  packet  driver  installation  and  configuration  procedure  for 
the  respective  platforms. 

1.  Configuration  of  Computers  in  the  LAN 

The  application  software  is  installed  on  each  computer  in  a  folder  (directory)  titled 
Internet.  Most  of  the  applications  are  compressed  and  require  expansion.  On  Macintosh 
platforms  install  the  self-extracting  program  Stuffit-Expander  from  ihe  Macintosh  disk  1  of 
5  first.  All  other  Macintosh  applications  can  be  installed  by  dropping  them  on  top  of  the 
expander  icon.  The  Windows  extraction  program  is  WinZip.  WinZip  is  a  self-extracting 
executable  file.  Copy  WinZip  to  a  temporary  file  in  the  file  manager  before  executing,  then 
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follow  the  installation  prompts  as  they  appear.  The  remainder  of  the  Windows  applications 
can  be  expanded  by  double-clicking  on  the  files  with  .zip  extensions.  Some  Windows 
applications  may  require  the  execution  of  setup  files  or  modification  of  the  path  in  the 
autoexec.bat  file.  Refer  to  the  application's  supporting  documentation  for  specific 
installation  instructions. 

2.  Configuration  of  a  Diskless  LAN 

The  software  suite  selected  for  Monterey  BayNet  was  designed  to  be  as  inexpensive 
as  practical  while  maintaining  functionality.  As  a  result  the  software  is  not  networkable,  i.e. 
it  is  for  single  users  not  multiple  shared  users.  This  implies  that  the  application  software 
must  reside  on  each  individual  platform  in  order  to  give  that  platform  the  complete 
fimctionality  of  the  associated  application.  If  the  software  is  called  fi'om  a  file  server  then 
only  one  user  will  be  able  to  access  the  application  at  a  given  time. 

El  Sausel  Middle  School  in  Salinas  California  operates  a  (mostly)  diskless  LAN. 
Each  computer  is  equipped  with  a  boot  ROM  or  boots  from  a  floppy  disk  [Alvarez,  95]. 
Users  login  to  the  Novell  file  server  to  load  Windows  and  the  Internet  applications. 
Configuration  of  terminals  in  a  diskless  LAN  is  nontrivial  and  beyond  the  scope  of  the 
configuration  team's  experience.  El  Sausel  employed  the  services  of  a  Novell  CNE  to 
configure  their  LAN.  Unfortunately,  because  the  software  suite  is  not  networkable,  only 
one  user  can  access  each  Internet  application  at  a  given  time.  This  is  not  a  side  effect  of  a 
poorly  designed  network.  Application  servers  are  desirable  in  LANs.  This  is  a  function  of 
the  low-cost  shareware  software  suite.  Networkable  software  with  the  same  functionality 
or  better  is  available  for  a  substantial  fee.  Other  newer  computers  on  the  same  LAN  do 
have  hard  drives  and  are  enjoying  full  Internet  functionality. 
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3.  Configuring  Eudora  Mail  Program  in  a  Multi-User  Environment 


Eudora  is  the  only  user-specific  software  application  in  the  shareware  suite.  It  is 
necessary  to  set  Eudora  so  that  the  personal  configuration  settings  of  each  user  are  drawn 
from  a  personal  disk.  This  prevents  mail  from  being  sent  out  under  a  false  user  name.  In 
Windows  this  is  accomplished  by  the  configuration  outlined  in  Figure  1.1.  The  Macintosh 
configuration  of  Eudora  for  multi-users  is  outlined  in  Figure  7.3. 


•  Create  a  new  directory  called  c;\eudora  and  copy  weudora.exe  into  it. 

•  Create  a  directory  called  c;\eudora\temp 

•  Add  the  following  environment  variable  to  your  autoexec.bat  file: 

Set  tirp=c  :  \ eudora \  temp 

•  Add  Eudora  as  a  new  program  item  to  a  the  Internet  Program  Group. 
•Modify  the  Eudora  program  Item  as  follows; 

Description:  weudora 

Command  Line:  c :  \ eudoraXweudora .  exe  a :  \ 

Working  Directory:  a :  \ 


Figure  7.2  Multi-user  Ewifora  Configuration  Under  Windows  [Beckley,  94]. 


•  Install  Eudora  on  the  Macintosh  hard  drive  with  no  configuration  parameters. 

•  Store  each  user's  Eudora  Settings  File  on  a  floppy  disk. 

Figure  7.3  Multi-user  Configuration  on  a. Macintosh  [Lapp,  95]. 

In  both  cases  a  unique  diskette  for  each  user  will  be  required.  To  operate  in  the 
Windows  environment  the  user  will  insert  the  disk  into  drive  "A;"  and  then  double  click  on 
the  Eudora  icon  in  the  Internet  group.  In  iht  Macintosh  case  the  user  will  click  on  the 
Eudora  icon  within  his  disk.  In  both  cases  this  will  start  Eudora  with  the  individual's  unique 
configuration  settings. 
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4.  Responsible  use  of  CU-SeeMe  in  Monterey  BayNet 

CU-SeeMe  is  an  interesting  and  powerful  point-to-point  videoconferencing 
application  [Cogger,  95],  Site  administrators  need  to  be  advised  that  irresponsible  CU- 
SeeMe  usage  can  cause  adverse  effects  in  LAN  and  WAN  response.  CU-SeeMe  requires 
large  bandwidth  and  creates  a  continuous  stream  of  data  through  the  Frame  Relay  cloud. 
Recall  that  Frame  Relay  technology  is  based  upon  the  transmission  of  variable  length 
Frames  over  virtual  circuits.  Imposing  a  continuous  stream  of  data  over  the  Frame  Relay 
circuitry  effectively  removes  that  amount  of  bandwidth  from  being  shared  with  other  clients. 

Read  the  accompanying  documentation  provided  with  CU-SeeMe  before  using  the 
application.  In  particular  read  and  comply  with  the  recommendations  on  bandwidth 
adjustment.  Do  not  transmit  at  greater  then  80Kbps  on  the  WAN.  The  best  method  of 
controlling  CU-SeeMe  access  is  to  limit  CU-SeeMe  installation  to  supervised  machines. 

56  Kbps  Monterey  BayNet  sites  should  limit  CU-SeeMe  access  to  a  single  platform.  The 
bottom  line:  CU-SeeMe  can  clobber  the  network  so  use  it  sparingly  and  carefully. 

E.  SUPPORT 

Monterey  BayNet  is  a  fully  operational  network  providing  services  today  which  are 
being  used  in  participating  schools  throughout  the  region.  The  initial  success  has  been 
largely  due  to  the  collective  efforts  of  the  PLA  net  design  team  in  planning,  implementing 
and  training.  In  order  for  the  technology  to  be  fully  integrated  into  the  classroom 
environment  it  must  be  a  reliable  and  dependable  product.  Educators  need  to  understand 
the  basics  of  the  technology,  the  use  of  the  applications,  and  know  that  the  product  will  be 
available  when  they  require  it.  This  implies  that  a  supporting  structure  of  educator  training 
and  WAN  management  must  be  in  place.  These  issues  are  currently  being  examined  by  the 
LLA  and  Monterey  BayNet.  The  remainder  of  this  chapter  will  highlight  the  critical  areas 
of  concern  for  Monterey  BayNet  future  sustainability  and  growth. 
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1. 


Formal  End  User  Training 


A  model  for  training  educators  in  the  use  of  the  application  software  must  be 
formalized  and  accessible.  The  I^LA  white  paper  recommended  the  implementation  of  a 
"train  the  trainer"  approach  [Brutzman,  94],  with  Tier  I  and  II  sites  being  responsible  for  the 
training  of  Tier  II  and  III  sites.  This  method  has  achieved  superior  results  in  conveying 
specific  material  to  limited  groups  on  an  ad  hoc  basis.  As  a  final  solution  the  "train  the 
trainer"  method  does  not  scale  to  the  scope  of  the  target  audience  now  attempting  to  access 
Monterey  BayNet.  Clearly  ad  hoc  training  is  valued  and  appreciated,  but  a  formal 
systematic  approach  which  is  designed  within  the  bounds  of  the  current  education  system  is 
required  in  order  to  reach  all  educators.  The  I^LA  and  Monterey  BayNet  can  assist  in  the 
development  of  the  content  for  user  training,  but  formalization  must  come  from  the  County 
OflBces  of  Education.  This  issue  closely  parallels  one  responsibility  of  a  Network 
Information  Center  (NIC)  yet  deserves  immediate  attention  in  the  absence  of  an  official 
NIC. 


2.  Network  Information  Center  (NIC)  Justification 

A  Network  Information  Center  (NIC)  is  the  group  or  organization  which  is 
primarily  responsible  for  user  services.  This  is  not  to  be  confused  with  connectivity.  The 
NIC  is  not  responsible  for  building  or  maintaining  network  connectivity.  User  services  can 
generally  be  grouped  into  "help-desk"  functions  such  as  establishing  new  user  accounts, 
answering  questions  about  application  software,  training  users,  developing  policy  and 
directing  users  toward  available  resources. 

By  default  the  county  offices  of  education  are  performing  the  NIC  function  within 
Monterey  BayNet  because  they  are  the  only  organization  which  can  currently  establish  and 
maintain  user  accounts.  The  Lloyd  Cyberstation  used  in  Monterey  BayNet  provides  a  GUI 
which  allows  non-technical  personnel  to  maintain  accounts  with  relative  ease.  The  larger 
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issue  is  the  manning  of  the  NIC  with  personnel  who  able  to  assist  users  with  their  questions 
and  have  the  authority  to  develop  and  cany  out  training  events. 

3.  Troubleshooting  Methodology 

The  site  network  administrators  require  training  in  network  administration 
particularly  in  troubleshooting  methodology.  Non-technical  site  administrators  with 
questions  are  currently  at  the  mercy  of  volunteer  schedules  and  a  single  WAN  administrator 
in  each  county  office  of  education.  A  clear  path  for  troubleshooting,  system  responsibility, 
and  points-of-contact  need  to  exist  and  be  understood  by  local  network  administrators. 

The  majority  of  network  errors  encountered  throughout  the  implementation  phase 
have  been  unrelated  to  WAN  connectivity.  Training  local  network  administrators  so  that 
they  can  recognize  that  WAN  connectivity  exists  (or  doesn't)  would  greatly  reduce  the 
burden  on  the  WAN  administrators.  The  final  goal  should  be  local  administrators  who  feel 
comfortable  that  they  can  isolate  a  problem  to  either  a  local  node,  WAN  access,  or  access 
beyond  Monterey  BayNet.  In  each  case  the  local  network  administrator  needs  to 
understand  who  the  responsible  agent  is  for  correcting  the  error  and  how  to  contact  them. 
This  issue  closely  parallels  one  responsibility  of  a  Network  Operations  Center  (NOC)  yet 
deserves  specific  attention  in  the  absence  of  an  official  NOC. 

4.  Network  Operation  Center  (NOC)  Justification 

A  Network  Operations  Center  (NOC)  is  the  group  or  organization  responsible  for 
the  day-to-day  maintenance  of  the  WAN.  This  is  accomplished  through  the  monitoring  of 
online  statistics  including  traffic  patterns,  congestion  reports  and  data  fi'om  SNMP  clients. 
Many  software  packages  exist  which  aid  in  the  recognition  of  network  problem  areas. 
Unfortunately  resolution  of  these  problems  must  be  accomplished  manually  and  often 
requires  significant  technical  expertise.  Nevertheless  many  large  and  small  organizations  do 
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not  have  a  formalized  NOC.  All  organizations  have  a  person  or  persons  which  perform  that 
role,  with  or  without  the  aid  of  automated  monitoring  devices. 

The  Monterey  BayNet  NOC  function  is  currently  being  carried  out  by  the  collective 
members  of  the  I^LA  network  design  team  in  cooperation  with  the  county  office  of 
education  WAN  administrators.  This  approach  is  not  sustainable.  The  responsibility  for 
communication  with  the  Internet  provider.  Pacific  Bell,  contractors,  and  numerous 
manufactures  has  too  many  legal  ramifications  to  remain  in  the  domain  of  volunteers, 
regardless  of  how  qualified  they  may  be.  By  default  the  role  of  the  NOC  falls  to  the  county 
offices  of  education.  This  function  can  also  be  easily  outsourced  to  any  competent  service 
provider  with  the  required  facilities  and  staff.  The  PLA  is  working  with  Monterey  BayNet 
to  resolve  NOC  transition  requirements. 

F.  IMPLEMENTATION  SUMMARY 

The  Monterey  BayNet  WAN  is  being  successfully  implemented  in  a  three  phase 
process  which  includes  initial  site  inspection,  informal  follow-up,  and  installation.  To  date 
25  of  the  43  CalREN  sites  are  online  and  installation  efforts  continue.  Monterey  BayNet  is 
providing  all  of  the  services  specified  in  the  end  user  requirements.  The  technical  problems 
of  implementation  are  rapidly  giving  way  to  human  ones.  The  need  for  consistent  and 
available  training  on  the  use  of  the  software  applications  provided,  as  well  as  the  need  for  a 
readily  available  information  and  assistance  center  are  the  driving  factors  of  the  next  phase 
of  the  implementation.  The  implications  of  delaying  the  implementation  of  a  full  scale  NIC 
and  NOC  could  be  cause  for  concern. 

Areas  for  continuing  research  include  NIC  and  NOC  design  and  deployment,  policy 
development  in  the  K-12  Internet  environment  and  models  of  technology  integration  in  the 
classroom.  In  the  area  of  human  resource  management  further  research  could  study  the 
reaction  of  technology  intervention  in  the  Monterey  BayNet  education  system.  New  lines 
of  communication  are  being  formed  by  technology  in  education  and  the  long  term  result 
may  be  nothing  short  of  full  scale  restructuring  of  the  education  model. 
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Vm.  APPLICABILITY  TO  DEPARTMENT  OF  THE  NAVY  (DoN)  SHORE 

COMMANDS 


A.  INTRODUCTION 

The  Monterey  BayNet  project  has  numerous  learning  points  that  transition  directly 
from  the  K-12  environment  into  wide  area  networking  efforts  within  Department  of  the 
Navy  shore  commands.  The  Monterey  BayNet  effort  focused  on  a  population  of  end 
users  with  minimal  networking  skill  levels  sparsely  distributed  over  a  large  geographic 
region.  Using  commercial  off  the  shelf  (COTS)  products  and  requiring  no  new  studies, 
this  group  of  volunteers  implemented  a  WAN  capable  of  high-speed  communication  of 
voice,  data  and  images. 

B.  REQUIREMENTS  DEFINITION 

Monterey  BayNet  spent  considerable  time  attempting  to  define  the  baseline  system 
requirements  for  end  users.  This  first  step  in  the  systems  development  life  cycle  is  critical 
in  that  it  forms  the  foundation  for  network  design  and  applications  development 
[Whitten,  89].  The  process  included  a  thorough  review  of  available  K-12  networking 
documentation,  applicable  grant  documentation  and  most  importantly  end  user  interview 
and  observation.  The  requirements  which  were  defined  in  this  process  played  a  leading 
role  in  the  subsequent  development  of  the  software  applications,  minimum  recommended 
personal  computer  hardware,  telecommunications  service  selection,  and  implementation 
methodology. 

Understandably  defining  end  user  requirements  is  much  like  trying  to  paint  a 
moving  train,  but  the  time  spent  understanding  the  scope  of  the  problem  and  the  expected 
outcomes  clearly  enabled  the  net  design  team  to  focus  its  efforts  on  a  shared  vision. 
Further  refinement  of  the  end  user  requirements  will  be  easier  now  that  there  are  tools  in 
place  to  measure  and  evaluate. 
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c. 


DESIGNING  FOR  GROWTH 


The  network  design  team's  focus  on  scalability  in  every  aspect  of  design  is  critical 
to  the  long  term  success  of  the  network.  In  LAN  design  recommendations  were  focused 
toward  the  implementation  of  lOBASE-T  designs  to  allow  migration  paths  for  further 
network  expansion.  The  physical  infrastructure  recommended  the  installation  of  upgraded 
UTP,  where  new  wire  was  required,  to  allow  future  expansion  to  100BASE-T.  In  WAN 
design  the  recommended  entry  level  was  128  Kbps  to  allow  future  increases  in  frame  rate 
without  the  need  to  invest  in  additional  hardware.  The  one  fact  that  can  be  relied  upon  is 
that  networks  will  grow  in  size  and  applications  will  require  increasingly  higher  data 
transfer  rates.  Monterey  BayNet  and  the  Monterey  BayNet  sites  have  the  ability  to 
expand  in  both  directions. 

D.  STANDARDIZATION 

Early  standardization  of  hardware  increased  the  manageability  of  the  network. 

The  configuration  team  was  required  to  learn  only  a  few  systems  in  order  to  effectively 
connect  sites.  Standardization  also  assured  interoperability  within  the  WAN.  The 
economies  of  scale  generated  by  group  purchase  techniques  generated  cost  savings  as  well 
as  manufacturer  attention  and  support  for  the  project. 

E.  COST  REDUCTION 

The  Monterey  BayNet  project  achieved  dramatic  results  in  an  extremely  cost 
conscious  environment.  Similar  methods  applied  in  DoN  networking  projects  may  yield 
the  same  result.  No  new  studies  were  required  or  requested  in  the  design  and 
implementation  of  the  network.  All  solutions  were  COTS  products  and  all  technology 
used  was  proven  in  industry  prior  to  the  network  design  team's  consideration.  Savings  at 
the  local  level  were  promoted  through  the  effective  evaluation  of  existing  infrastructure. 
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Many  schools  were  able  to  reuse  excess  capacity  wiring  for  LAN  installation.  The  use  of 
on-site  personnel  to  run  new  cable  installations  greatly  reduced  cost  to  schools. 

F.  MAEVTAINABILrrY 

Simple  Network  Management  Protocol  (SNMP)  clients  and  WAN  management 
applications  are  valuable  tools  to  assist  personnel  in  the  management  of  a  WAN.  These 
tools  are  not  a  substitute  for  knowledgeable  technicians  who  can  address  problems  as  they 
are  identified.  The  question  to  be  considered  in  planning  NIC  and  NOC  functions  is  not  a 
technical  question  as  much  as  it  is  a  human  one.  NIC  and  NOC  staffing  and  a  plan  on  how 
to  address  technical  and  human  issues  are  much  more  valuable  than  a  software  suite  which 
allows  an  operator  to  pinpoint  a  problem  without  the  means  to  correct  it. 

G.  SUMMARY 

Monterey  BayNet  serves  as  a  practical  reminder  that  networking  solutions  must  be 
oriented  to  the  end  user  and  not  the  technology.  Wide-area  network  connectivity  can  be 
achieved  in  a  manner  which  optimizes  economy  and  design.  Infrastructure  design  and 
installation  can  be  accomplished  with  nontechnical  personnel  at  great  savings.  The 
management  and  maintenance  of  a  network  is  simplified  though  standardization.  Finally 
maintenance  is  a  personnel  problem,  not  a  technical  problem.  Technical  issues  have 
technical  solutions,  whereas  people  issues  require  people  solutions. 
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IX.  CONCLUSIONS 


Monterey  BayNet  works! 

Students  and  educators  began  collaborating  via  the  Monterey  BayNet  on  March 
24th  1995.  The  network  is  obviously  still  in  its  infancy  and  there  are  a  number  of 
personnel  issues  to  resolve,  but  the  end  user  requirements  which  were  defined  in  Chapter 
rv  are  being  met  and  exceeded.  Monterey  BayNet  provides  an  information  infrastructure 
that  enables  such  a  fundamental  shift  in  the  educational  paradigm  that  it  may  take  years  to 
fully  resolve  the  issues  of  integration  within  the  educational  system  and  the  impact  on 
teaching  and  learning.  The  reactions  of  the  students  and  parents  of  the  Monterey 
Academy  of  Oceanographic  Sciences  (MAOS)  clearly  indicate  that  student  and  parent 
interest  is  enormous.  Students  and  parents  alike  were  captivated  by  the  concept  of  being 
able  to  share  their  research  with  the  world.  The  end  product  at  MAOS  was  a  dedicated 
student  effort  to  create  a  home  page  which  expressed  their  research  project  results  as  well 
as  their  enthusiasm.  The  URL  for  MAOS  is  http://205. 15 5. 54. 2/maos/home. html 
[Pool,  95], 

The  key  to  Monterey  BayNet  success  has  been  the  dedication  of  the  individuals 
involved  with  the  collaborative  effort.  A  single  expert  does  not  exist.  Interested 
educators,  researchers  and  technicians  have  doggedly  pursued  a  common  vision  to 
fioiition.  The  fact  that  Monterey  BayNet  has  arrived  at  this  stage  after  little  more  than  one 
year  is  nothing  short  of  remarkable  and  speaks  volumes  about  the  strength  of  the 
collaborative  effort  in  Monterey  Bay. 

A  second  key  contributor  to  success  has  been  the  continual  focus  on  the  end  user. 
This  author  finds  it  remarkable  that  some  sites  have  networked  every  room  of  their  entire 
campus  without  outside  assistance.  The  technology  transfer  discussed  in  Chapter  V 
combined  with  the  information  presented  in  the  appendices  is  literally  all  of  the  guidance 
used  in  most  cases  throughout  Monterey  BayNet.  Student  volunteers  from  the  Naval 
Postgraduate  School  and  Cabrillo  College  assisted  in  the  technology  transfer  process  by 
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conducting  walk-thru  inspections,  usually  learning  more  from  answering  the  end  user 
questions  than  the  end  user  did. 

The  final  linchpin  was  the  terrific  assistance  provide  by  Pacific  Bell,  Cisco,  and 
Lloyd  Internetworking.  The  final  implementation  of  the  WAN  could  not  have  been 
coordinated  better  or  benefitted  from  stronger  partners.  The  relationships  fostered  with 
these  corporations  have  greatly  assisted  the  members  of  the  PLA  net  design  team  to 
understand  the  technical  issues  as  they  developed. 

Collaboration  implies  cooperation,  a  give  and  take  relationship  which  is  founded 
on  trust  and  vision.  While  at  times  the  speed  of  the  consortia  seemed  appallingly  slow,  it 
is  equally  true  that  when  a  decision  is  finally  reached  it  has  been  completely  examined, 
often  repeatedly.  This  is  beneficial  to  the  final  product,  provided  that  the  central  focus 
does  not  waver.  Monterey  BayNet's  measure  of  success  has  continually  remained  the 
number  of  students  and  teachers  online.  This  focus  has  been  crucial  in  achieving  success 
to  date. 

Further  research  continues  within  the  FLA  net  design  team.  The  next  phase  of 
Monterey  BayNet  development  must  veer  radically  from  the  technical  issues  to  address  the 
people  and  policy  issues.  Training,  user  support,  manning  of  a  network  information  center 
(NIC),  and  providing  a  plan  for  technical  support  (NOC  functions)  are  all  issues  which 
must  be  resolved  for  Monterey  BayNet  to  be  sustainable  after  the  CalREN  grant  expires. 

A  key  ingredient  again  must  be  end  user  "buy  in".  This  author  feels  strongly  that  the  best 
mode  of  accelerating  educator  acceptance  of  technology  is  to  grant  them  access  to  the 
same  applications  from  home.  Dial-in  service  limited  to  educators  can  allow  the  educators 
the  leisure  of  learning  "what"  and  "how"  from  home,  creating  a  "Tier  IV"  of  access. 
Limiting  that  access  to  educators  is  an  important  policy  question.  Monterey  BayNet  may 
not  want  to  place  themselves  in  a  position  where  they  are  competing  with  local  Internet 
providers  for  the  home  dial-in  market,  namely  parents.  On  the  other  hand,  providing  some 
additional  access  might  support  financial  sustainability. 
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In  summary  the  processes  used  to  develop  Monterey  BayNet  all  focused  on 
meeting  the  requirements  of  the  end  user  today  and  in  the  future.  Design  efforts  stressed 
upward  bandwidth  transition  paths  and  well  as  LAN  expansion  paths.  The  WAN  stressed 
equipment  standardization  to  assure  interoperability  and  management  sanity.  SNMP  was 
recommended  to  allow  future  growth  toward  remote  WAN  monitoring  to  assist  end  users, 
Every  facet  reflects  end  user  ease  of  use,  manageability,  and  scalability. 
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APPENDIX  A.  MACINTOSH  SOFTWARE  DOWNLOAD  SITES 


The  following  is  a  list  of  the  Monterey  BayNet  recommended  software  for 
Macintosh  platforms.  This  list  reflects  the  latest  versions  of  software  as  of  this  writing. 
Pointers  to  download  sites  listed  can  be  found  at  http://monterey.kl2.ca.us/ 
macsoft.html.  This  list  is  maintained  by  the  Monterey  BayNet  system  administrator  and 
will  reflect  updates  as  they  are  implemented  within  Monterey  BayNet. 

Not  all  of  the  software  is  free.  Review  the  copyright  of  every  piece  of  software 
that  is  being  installed.  It  is  the  responsibility  of  the  system  administrator  to  ensure 
compliance  with  all  license  and  copjoight  requirements. 

File  extensions  (.sit,  .sea,  .bin  and  .hqx)  are  used  to  indicate  what  format  the  file 
has  been  stored  in.  The  hqx  (BinHexed)  extension  is  normal  and  will  be  transparent  to 
Macintosh  users.  The  same  holds  true  for  files  with  the  .bin  (Binary)  extension.  All  files 
with  the  extension  .sit  (StufF-It)  will  have  to  be  extracted  with  the  Stuffit  Expander  or 
similar  application.  The  extension  .sea  (Self  Extracting  Archive)  indicates  that  the  file  will 
automatically  expand  itself  Each  application  has  a  compressed  file  size  listed.  Total 
system  disk  space  required  for  a  complete  software  installation  is  approximately  45 
megabytes  (MB). 

MacTCP  PROPRIETARY 

MacTCP  is  the  software  which  enables  TCP/IP  connectivity.  MacTCP  software  comes 
bundled  with  the  system  7.5  operating  system.  All  older  operating  systems  require  a 
licensed  copy  o^ MacTCP.  The  easiest  way  to  obtain  MacTCP  is  through  the  purchase  of 
The  Internet  Starter  Kit  for  the  Macintosh  (currently  $29.95)  at  many  bookstores 
[Engst,  94], 

Netscape  -  Version  1 .  IN  -  Windows  version  available.  FREE  EDUCATIONAL  USE 
A  graphical  WWW  browser. 

ftp: //ftp.  mcom.  com./netscape/mac/netsccq)e_l.  IN.  hqx 
1625  KB 

Eudora  -  Version  2.1.1-  Windows  version  available.  FREEWARE 

Send  and  receive  electronic  mail. 

ftp: //ftp.  qualcomm.  com/quest/mac/eudora/1. 5/eudoral52fat.  hqx 
649  KB 

NewsWatcher  -  Version  20b27  FREEWARE 

A  news  reader.  Note  that  news  groups  must  be  made  available  from  the  Internet  provider. 
ftp://ftp.acns.nwu.edu/pub/newswatcher/newswatcher-20b27.sea.hqx 
625  KB 
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FREEWARE 


Fetch  -  Version  2.1.2 

A  File  Transfer  Protocol  (FTP)  application  for  th&  Macintosh. 
file://ftp.dartmouth.  edu/pub/mac/Fetch_2. 1. 2.sit.hqx 
363  KB 

Anarchie  -  Version  1 .4  FREEWARE 

An  FTP  and  Archie  client.  Archie  is  a  method  of  searching  FTP  sites  for  information. 
ftp: //boombox,  micro,  tmn.  edu/pub/gopher/Macintosh-TurboGopher/helper-applications/ 
Anarchie- 140.  sit.  hqx 
490  KB 

Telnet  -  Version  2.6  -  Windows  version  available.  FREEWARE 

Enable  virtual  terminal  access  to  remote  hosts. 
file: //ftp.  ncsa.  uiuc.  edu/Mac/T ?lnet/T zlnet2. 6.  sit.  hqx 
167  KB 

TurboGopher  -  Version  2.0b7  -  Windows  version  available.  FREEWARE 

A  Gopher  client  for  the  Macintosh.  Enables  the  download  of  files  from  Gopher  servers. 
ftp://boombox.micro.  umn.  edu/pub/gopher/Macintosh-TurboGopher/T urboGopher2. 0.sea.  hqx 
316KB 

GifConverter  SHAREWARE  $40 

Graphic  image  viewer  and  processor.  Reads  and  writes  the  following  graphics  file  formats; 
GIF,  MacPaint,  PICT,  RIFF,  RLE,  Thunderscan,  Startup  Screen,  TIFF  and  JPEG. 
file: //ftp.  ncsa.  uiuc.  edu/Mac/Mosaic/Helpers/gif-converter-23 7.  hqx 
474  KB 

JPEGView  -  Version  3.3. 1  POSTCARDWARE 

Graphic  image  viewer  and  processor.  Reads  and  writes  the  following  graphics  file  formats: 
JPEG,  JFIF,  GIF,  PICT,  Baseline  and  LZW-compressed  TIFF,  Windows  BMP,  Startup 
Screen,  and  MacPaint. 

file: //ftp.  ncsa.  uiuc.  edu/Mac/Mosaic/Helpers/jpeg-view-231.  hqx 
769  KB 

SoundMachine  FREEWARE 

Audio  file  player  for  SND/AU  and  AIFF/AIFC  formats. 

file: //ftp.  ncsa.  uiuc.  edu/Mac/Mosaic/Helpers/sound-machine-21.  hqx 

74  KB 

Sparkle  -  Version  23 1  FREEWARE 

MPEG  and  QuickTime  movie  viewer. 
file://ftp.ncsa.  uiuc.  edu/Mac/Mosaic/Helper s/sparkle-231,  hqx 
1109KB 
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FREEWARE 


SimplePlayer 
A  quicktime  movie  viewer 

file://ftp.ncsa.  uiuc.  edu/Mac/Mosaic/Helpers/fast-player-1 10.  hqx 
13  KB 

Stuffit  Expander -Ntrsionh. 5. 2  FREEWARE 

Create  compressed  archives  and  decompress  common  Macintosh  archived  formats. 
file://ftp.ncsa.uiuc.edu/Mac/Mosaic/Helpers/stuffit-expander-352.hqx 
186  KB 

DropStuff- Version  3.5.2  SHAREWARE  $30 

Enhanced  version  of  Stuffit  Expander.  Create  compressed  archives  and  decompress 
archived  formats  including  ZIP  (.zip)  and  ARC  (.arc)  archives;  AppleLink  (  pkg) 
packages;  gzip  (.gz),  Unix  Compress  (.Z),  UUencoded  (.uu),  and  Stuffit  files  (  sit). 
file://ftp.ncsa.  uiuc.  edu/Mac/Mosaic/Helpers/drop-stuff-with-ee-352.  hqx 
521KB 

NCSA  Collage  -  Version  1.2-  Windows  version  available.  FREEWARE 

A  shared  whiteboard  application. 

file: //ftp.  ncsa.  uiuc.  edu/Mac/Collage/Collage  1 . 2 /Collage  1. 2.  sit.  hqx 
661  KB 

BBEdit Lite  -  Version  3.0  FREEWARE 

A  high  performance  text  editor. 

file: //ftp.  ncsa.  uiuc.  edu/Mac/Mosaic/Helpers/bbedit-lite-30.  hqx 
392  KB 

B^^(ir?-html-extension  FREEWARE 

Add-on  extensions  to  BBEdit  Lite  which  enable  use  as  an  HTML  editor. 
file: //ftp.  ncsa.  uiuc.  edu/Mac/Mosaic/Helpers/bbedit-html-bS.  hqx 
78  KB 

CU-SeeMe  -  Windows  version  available.  FREEWARE 

Point-to-point  videoconferencing. 

fip://CU-SeeMe.comell.edu/pub/CU-SeeMe/Mac.CU-SeeMe0.80b2/CU-SeeMe.68k0.80b 

2.bin 

224  KB 

Disinfectant  -  Version  3.5  FREEWARE 

A  program  designed  to  detect  and  remove  all  known  Macintosh  viruses. 
fip://ftp.acns.nwu.edu/pub/disinfectant/disinfectant36.sea.hqx 
232  KB 
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MacTCP  Watcher  -  Version  1.12  FREEWARE 

Application  which  displays  IP  and  DNS  information.  Network  testing. 
ftp://redback.cs.iiwa.edu.au/Others/PeterLewis/MacTCPWatcher-112.sit 
79  KB 

BLUE  SKIES  -  Version  1 . 1  FREEWARE 

Interactive  weather  information. 

gopher: //groundhog,  sprl.  umich.  edu/1  l/Software/Blue-Skies_yl.  1.  sea.  hqx 
251  KB 

MacWeather  -  Version  2.0.4  FREEWARE 

Current  weather  information  and  forecasts. 

ftp  : //cirrus.  sprl.umich.edu/pub/Other_Software/Weather_Software/macweather2. 04.hqx 
116KB 

Adobe  Acrobat  -  Windows  version  available. 

A  Portable  Document  Format  (.PDF)  file  viewer. 
ftp -.//boombox. micro. umn.  edu/pub/gopher /Macintosh 
AcrobatReader/AcrobatReader2. 0.  l.hqx 
2919  KB 

GhostScript  -  Windows  version  available.  FREEWARE 

A  PostScript  (.PS)  file  viewer. 
ftp: //ftp.  cs.wisc.  edu/pub/ghost/aladdin/mac/ 

714  Kbps  macgs-vl.O-files.sit  -  G/jost&r/pt  files  and  documentation 
438  Kbps  macgs-vl.0-68k.sit  -  the  application  compiled  for  68020  or  better 

2782  Kbps  macgs-v  1.0-fonts. sit  -  the  standard  GAo5r,Scn/7/ 3.0  fonts 

17  Kbps  manual.txt  -  the  manual  as  unformatted  text 

1  Kbps  readme.txt  -instructions! 

InterSLIP  FREEWARE 

Serial  Line  Internet  Protocol  (SLIP)  makes  TCP/IP  communication  possible  via  modem. 
http://www.  Utah.  edu/HTMLJ/locs/InterSLlP /InterSLIP.  html 
267  KB 

MacPPP  FREEWARE 

Point-to-Point  Protocol  (PPP)  makes  TCP/IP  possible  communication  via  modem. 
MacPPP  is  bundled  with  MacTCP  when  you  purchase  The  Internet  Starter  Kit 
[Engst,  94]. 

ftp://ftp.merit.edu/intemet.  tools/ppp/mac/macppp2. 0.  l.hqx 
75  KB 


FREEWARE 

-TurboGopher/helper-applications/ 
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APPENDIX  B.  WINDOWS  SOFTWARE  DOWNLOAD  SITES 


The  following  is  a  list  of  the  Monterey  BayNet  recommended  software  for 
Windows  platforms.  This  list  reflects  the  latest  versions  of  software  as  of  this  writing. 
Pointers  to  download  sites  listed  can  be  found  at  http://monterey.kl2.ca.us/ 
ibmsoft.html.  This  list  is  maintained  by  the  Monterey  BayNet  system  administrator  and 
will  reflect  updates  as  they  are  implemented  within  Monterey  BayNet. 

Not  all  of  the  software  is  free.  Review  the  copyright  of  every  piece  of  software 
that  is  being  installed.  It  is  the  responsibility  of  the  system  administrator  to  ensure 
compliance  with  all  license  and  copyright  requirements. 

File  extensions  (.zip)  are  used  to  indicate  what  format  the  file  has  been  stored  in. 
All  files  with  the  .zip  (PKWare  compression)  extension  will  have  to  be  extracted  with  the 
WinZip  application.  Each  application  has  a  compressed  file  size  listed.  Total  system  disk 
space  required  for  a  complete  software  installation  is  approximately  45  Megabytes  (MB). 


Trumpet  Winsock  Version  2.0 
The  software  which  enables  TCP/IP  connectivity. 
ftp.  cica.  indiana.  edu/ftp/pub/pc/win3Avinsock/twsk20b.  zip 
179  KB 


SHAREWARE  $25 


Netscape  -  Version  I.IN  -Macintosh  version  available. 
A  graphical  WWW  browser. 
ftp: //ftp.  mcom.  com/netscape/windows/ns  16-1 00.  exe 
706  KB 


FREE  EDUCATIONAL  USE 


Eudora  -  Version  1.4.3  -  Macintosh  version  available. 

Send  and  receive  electronic  mail. 

ftp.  cica.  indiana.  edu/ftp/pmb/pc/win2/winsock/eudorl43.  exe 
303  KB 


POSTCARDWARE 


^/nFVNNTP  newsreader  FREEWARE 

A  news  reader.  Note  that  news  groups  must  be  made  available  by  the  Internet  provider. 
ftp.cica.indiana.edu/ftp/pub/pc/win3/winsock/winvn926.zip 
176  KB 


FTP  -  Version  94.03.25  FREEWARE 

A  File  Transfer  Protocol  (FTP)  application  that  enables  the  download  (and  upload)  of  files 
from  FTP  servers. 

ftp: //ftp.  csusm.  edu/cwis/winworld/winsock/wsjtp.  zip 
69  KB 


83 


Archie  FREEWARE 

An  FTP  and  Archie  client.  Archie  is  a  method  of  searching  FTP  sites  for  information. 
ftp://ftp.csusm.edu/cwis/winworld/wmsock/wsarchie.zip 
159  KB 

PING,  WINCHAT,  View,  Winarch,  Trumptel(Telnet)  FREEWARE 

A  group  of  standard  applications  which  allow  you  to  retrieve  IP  and  DNS  information, 
conduct  network  tests,  perform  online  "chat"  sessions  with  other  users,  and  enable  virtual 
terminal  access  to  remote  hosts. 
ftp: //ftp.  utas.  edu.  au/pc/trumpet/winsock/winapps2.  zip 
124  KB 

WinGopher  -  Macintosh  version  available.  FREEWARE 

A  Gopher  client  for  Windows.  Enables  the  download  of  files  fi'om  Gopher  servers. 
bcinfo.  be.  edu/pub/bcgopher/BCC08BA  3. EXE 
170469bytes 

LView  3 1  FREEWARE 

Graphic  image  viewer  and  processor. 

file: //gatekeeper. dec.  com/. f/micro/msdos/win3/desktop/lview31.zip 
234  KB 

Wham  -  Version  1.31  $20-$30  DONATION  ENCOURAGED  -  SHAREWARE 

Audio  file  viewer  and  processor. 

ftp://gatekeeper.dec.com/pub/micro/msdos/win3/sounds/whaml31.zip 
138  KB 

Quicktime  -  Version  1.1-  Macintosh  version  available.  SHAREWARE 

A  quicklime  movie  viewer. 

bcinfo.  be.  edu/pub/bcgopher/qtwl  1.  exe 

622  KB 

MPEGXING  FREEWARE 

An  MPEG  movie  viewer. 

ftp -.//bcinfo.  be.  edu/pub/bcgopher/MPEGEXING.EXE 
478  KB 

WinZip  5.5a  w/built-in  ZIP+UNZIP;  Drag  &  Drop  SHAREWARE  $29 

Create  compressed  archives  and  decompress  common  Windows  archived  formats. 
http://www.  acs.  Oakland  edu/oak/Sim  Tel/win3/winzip55.  exe 
284  KB 
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FREEWARE 


NCSA  Collage  for  Winsock  -  Macintosh  version  available. 

A  shared  whiteboard  application. 
ftp.  cica.  indiana.  edu/pub/pc/win5/winsock/col _12bl.zip 
204  KB 

Hotmetal  -  HTML  Editor  FREE  FOR  EDUCATIONAL  USE 

A  Hyper  Text  Markup  Language  (HTML)  editor. 

gatekeeper. dec.com/pub/net/infosys/NCSA/Web/html/hotmetal/hotmetal.exe 
1361KB 

CU-SeeMe  -  Macintosh  version  available.  FREEWARE 

Point-to-point  videoconferencing. 

ftp://CU-SeeMe.  Cornell.  edu/pub/video/PC.  CU-SeeMe 

224  KB 

F-Prar  Anti-virus  SHAREWARE  $20 

Virus  detection  and  removal  software. 
http: //id. proper,  com/pc/files/fprot.  zip 
514  KB 

Adobe  Acrobat  Reader  -  Macintosh  version  available.  SHAREWARE 

A  Portable  Document  Format  (  pdf)  file  viewer. 
ftp://ftp.cuiobe.com/pub/adobe/Applications/Acrobat/Windows 
1438  KB 

GhostScript  for  Windows  -  Macintosh  version  available.  FREEWARE 

A  PostScript  (.ps)  file  viewer. 

http://www.  cs.  wise.  edu/~ghost/ghostscript/obtaina.  html 

504  KB  gs333ini.zip  -  Configuration,  initialization,  and  example  files. 

440  KB  gs333win.zip  -  MS-Windows  16  bit  version. 

1344  KB  gs333fiil  .zip  -  GhostScript  standard  fonts. 

576  KB  gsviewl3.zip  -  G.S'v/^  previewer. 
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APPENDIX  C  EIA/TIA-568B  WIRING  SCHEME  IN  A  lOBASE-T  PLUG 


This  is  a  drawing  of  the  lOBASE-T  plug  specified  in  the  IEEE  802.3  standard 
[IEEE,  90b].  The  connector  is  commonly  (and  improperly)  called  an  RJ-45.  The  proper 
name  is  an  eight  position  modular  plug.  It  connects  4  pairs  of  wires  as  shown  below.  The 
wiring  scheme  is  simple  in  concept,  yet  somewhat  time  consuming  in  practice.  Be  sure  to 
verify  all  wiring  with  a  lOBASE-T  tester  box  immediately  after  connection.  More 
information  on  the  design  of  lOBASE-T  local  area  networks  can  be  found  in  Chapter  V. 


This  is  an  6-Pc3sifon  lulodular  Plug, 
often  incorreotly  referred  te 
as  an  RJ-45. 


EIA/TIA-568B 
Wiring  Scheme 


10BASE-T  use 

6  Unused 

7  Unused 

6  DahReceire- 
5  Unused 
4  Unused 
^  DabReDewe  + 
2  DabTransmft- 
1  Dab  Transnift 


345 


67  8 


10BASE-T  wiring  specifies  an  S-positlon  jack  but  useson^  Orangek 

pairs  2  and  5  of  the  EIA/TIA-566B  scheme.  Pair  1  is  not  used 
because  that  position  is  used  in  conventbna!  telephone  service  and 
carries  voltage  when  the  telephone  rings.  This  voltage  would  damage  your  NIC. 
The  forth  coming  100BASE-T  standard  will  use  all  four  pairs. 


Pair  3  Green 


Figure  C.l  EIA/TIA-568B  wiring  scheme. 
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APPENDIX  D.  EXAMPLE  LAN  DESIGNS 


Local  area  network  (LAN)  design  was  discussed  in  detail  in  Chapter  V.  The 
following  designs  are  typical  of  those  that  have  been  built  within  Monterey  BayNet 
schools.  The  first  design  (Figure  D.l)  is  from  the  Main  Street  School  in  Soledad 
California.  Faculty  members  pulled  new  category  5  wire  from  a  central  lOBASE-T  hub 
located  at  the  MPOE  to  two  computer  labs  located  on  the  campus.  The  central  hub  has 
excess  capacity  (unused  jacks),  as  do  the  hubs  installed  in  the  two  classrooms.  This  will 
make  future  expansion  to  other  areas  on  the  campus  easy  and  affordable.  The  LAN  is 
connected  to  the  WAN  with  a  Cisco  2511  router  and  Adtran  TSU.  The  2511  will  also  act 
as  a  terminal  server,  allowing  dial-in  access  to  the  WAN  via  a  bank  of  8  modems.  Main 
Street  School  has  a  128Kbps  Frame  Relay  connection  to  Monterey  BayNet.  All  LAN 
internal  connections  use  Ethernet.  This  is  the  recommended  model  for  school  LAN  design 
i.e.  A  lOBASE-T  LAN  with  a  central  hub  at  the  MPOE  servicing  hubs  in  each  buildin 


Figure  D.l  Main  Street  School  lOBASE-T  LAN 


Seaside  High  School  (Figure  D.2)  has  a  10BASE2  backbone  serving  1 1  nodes. 
Two  of  the  nodes  are  hubs  which  allow  lOBASE-T  connections  to  12  Quadra  610s. 
Three  other  Quadras  are  attached  directly  to  the  backbone  in  the  reading  room.  The 
circulation  desk,  office  and  file  server  are  IBM  clones  with  486  processors.  Novell 
Netware  4. 1  is  the  network  operating  system.  The  LAN  is  connected  to  the  WAN  with  a 
Cisco  25 1 1  router  and  Adtran  TSU.  The  25 1 1  will  also  act  as  a  terminal  server,  allowing 
dial-in  access  to  the  LAN  via  a  bank  of  8  modems.  Seaside  High  has  a  128Kbps  Frame 
Relay  connection  to  Monterey  BayNet. 


Figure  D.2  Seaside  High  School  Library  lOBASE-2  LAN 


The  Monterey  Bay  Technology  Education  Center  (MBTEC)  and  Fitch  Middle 
School  share  a  common  campus.  A  single  384  Kbps  Frame  Relay  line  services  both  clients 
via  a  Cisco  2514  dual  port  router  (Figure  D.3).  IVffiTEC  has  a  10BASE2  backbone 
serving  a  single  node.  The  node  is  a  24  port  hub  which  is  directly  connected  to  a  second 
24  port  hub.  The  two  hubs  service  a  lOBASE-T  raceway  spanning  all  four  rooms  of  the 
MBTEC  facility.  Novell  Netware  4. 1  is  the  network  operating  system.  The  file  server  is 
physically  located  in  room  A-4. 

The  Fitch  Middle  School  LAN  is  a  lOBASE-T  network  originating  at  the  Cisco 
25 14  router  and  servicing  a  12  port  hub  in  the  library.  The  circulation  desk,  reference 
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area  and  file  server  are  IBM  clones  with  486  processors.  Novell  Netware  4. 1  is  the 
network  operating  system.  The  student  access  area  is  a  cluster  of  Macintosh  platforms. 
All  library  devices  are  connected  to  the  hub  with  Category  5  UTP  wire. 

Note  that  a  hub  was  not  placed  at  the  MPOE.  When  the  administration  building 
desires  to  connect  to  the  LAN  a  hub  will  be  required  at  the  MPOE.  The  present  design 
meets  all  current  requirements  and  allows  for  easy  expansion. 


Figure  D.3  Monterey  Bay  Technology  Education  Center  (MBTEC)  and  Fitch  Middle 
School  LAN's  connected  by  a  Cisco  2514  dual  port  router. 
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APPENDIX  E.  MONTEREY  BAYNET  EQUIPMENT  RECOMMENDATIONS 


These  are  the  original  Monterey  BayNet  equipment  recommendations.  Chapters 
V,  VI  and  VII  have  noted  repeatedly  the  benefits  of  equipment  standardization  throughout 
LAN  and  WAN  design.  It  is  also  be  noted  that  technology  evolves  rapidly,  delivering 
better  and  cheaper  products  to  market.  Always  consult  with  the  WAN  system 
administrator  and/or  Internet  provider  prior  to  purchasing  new  equipment.  The  following 
recommendations  were  published  in  March  1995  [Herbst,  95a].  Prices,  delivery  terms,  and 
warranty  are  subject  to  change,  caveat  emptor. 

Router: 

Cisco  2500  series: 

Cisco  2514  Dual  LAN  router  (recommended) 

Cisco  2501  Single  LAN  router 
Cisco  2511  Single  LAN  router  with  terminal  service 

CSU/DSU: 

Adtran. 

T1  CSU  for  128Kbps  thru  1.5Mbps  Frame  Relay  service 
Model  Adtran  TSU 

ADN  CSU  for  56Kbps  Frame  Relay  service  (not  scalable) 

Model  Adtran  56/64 


Ethernet  Card:  Eagle/Artisoft  ^^2000+  $74.83 

Smart  Hubs  (SNMP  agent  -  recommended): 

Asante  AH1012-12  w/SNMP  99-00028-01 

Asante  Netstacker  Base  24  99-00 1 88-0 1 

Cabletron  10  T 12  Port  SEHI-22 

Cabletron  10  T  24  Port  SEHI-24 

Allied  Telesyn  10  T  24  port  AT-3624TRS-15 

Non-InteUigent  Hubs  (not  recommended): 


Cabletron 

10  T  12  Port 

SEH-22 

$575.00 

Cabletron 

10  T  24  Port 

SEH-24 

$812.00 

Asante 

10  T  HUB  8  port 

99-00299-01 

$149.00 

Asante 

10  T  HUB  12  port 

99-00280-01 

$299.00 

Asante 

10  T  HUB  24  port 

99-00281-01 

$395.00 

$750.00 

$1199.00 

$1140.00 

$1430.00 

$673.00 


$902.00 

$225.00 
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Allied  Telesyn 

10  T  12  port 

AT-3612TR-15 

$517.40 

Allied  Telesyn 

10  T  12  port 

AT-3612TR-18 

$618.80 

Allied  Telesyn 

10  T  14  port 

AT-3624TR-15 

$777.40 

Allied  Telesyn 

10  T  14  port 

AT-3624TR-18 

$878.80 

Network  management  program  for  Windows  (Not  available  for  Mac) 

Castlerock  SNMPc  3600  Release  3.3 

AT-10070 

$257.00 
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APPENDIX  F.  REGISTERED  JACK  NUMBER  48  (RJ-48)  PINOUT  AND 
WIRING  BETWEEN  NIU  AND  CSU 


The  Figure  F.  1  shows  the  physical  wiring  installed  by  PacBell  at  the  minimum 
point  of  entry  (MPOE)  as  described  in  Chapter  VI.  Recall  that  PacBell  charges  for  the 
installation  of  the  RJ-48.  Monterey  BayNet  recommends  that  PacBell  install  the  RJ-48  in 
those  cases  where  the  RJ-48  is  not  collocated  with  the  PacBell  Network  Interface  Unit 
(NIU). 

Wiring  from  the  NIU  to  the  RJ-48  consists  of  2  pairs  of  24  gauge  wire.  The  pairs 
are  terminated  on  the  punchdown  block  of  the  RJ-48  as  described  in  the  RJ-48  pin 
connections  table  below  [Adtran,  94].  Note  that  the  RJ-48  pinout  varies  depending  upon 
the  type  of  channel  switching  unit  at  the  site. 

The  cable  from  the  RJ-48  to  the  CSU  is  provided  with  the  CSU.  The  cable  is  an  8 
position  modular  plug  to  8  position  modular  plug  wired  straight-thru  using  the  EIA/TIA- 
568B  wiring  scheme  discussed  in  Appendix  C. 


R1  LOOP  1  ^ 

T1  LOOP1 
R  LOOP  2  0; 

T  LOOP  2  ® 

T1  TO  CPE  0.^ 
R1  TO  CPE 
T  FROM  CPE  0  /I 
R  FROM  CPE  0  , 


IWPI  IT  NIU 


^  J  Orange 


INPUT 

From 

PacBell 


isH 


Output 
To  RJ-48 


RJ-«  ^ 

The  wiring  of  the  8  Position 

RJ-18  vanes.  J  tiiOduiarplugtoS 
See  table  below  Position  jack  on  CSU 


RJ-48  PIN  CONNECTIONS 
*IN  Adtran  TSU  use  Adtran  56/64  use 

1  R1  RXDATA  -  ring  R  TXD  ATA  -  ring 

2  T1  RXDATA  -  tip  T  TXDATA  -  tip 


unused 


unused 


R  TXDATA  -  ring  unused 
T  TXDATA  -  tip  unused 


6  unused 

7  unused 

8  unused 


unused 

T1  RXDATA -tip 
R1  RXDATA  -  ring 


Figure  F.l  RJ-48  pinout  and  wiring  between  NIU  and  CSU. 
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APPENDIX  G.  CHANNEL  SERVICE  UNIT/DIGITAL  SERVICE  UNIT 
(CSU/DSU)  CONFIGURATION 


Chapter  VI  described  the  role  of  the  CSU/DSU  in  the  WAN.  Figure  G.  1  is  the 
Adtran  T-1  Service  Unit  (TSU)  configuration  menu  tree  with  settings  for  a  128Kbps  site. 
The  Adtran  TSU  performs  the  role  of  both  CSU  and  DSU  [Adtran,  94],  The  Channel 
Service  Unit  (CSU)  function  allows  the  TSU  to  be  programmed  to  accept  any  number  of 
channels  up  to  a  full  T-1  service  rate  of  1.5  Mbps.  Each  channel  is  64Kbps.  128  Kbps  sites 
select  two  channels,  sites  with  rates  higher  than  128Kbps  adjust  the  number  of  channels 
accordingly.  The  Digital  Service  Unit  (DSU)  function  programs  the  position  of  the  data  in 
the  T-1  stream. 


FORMAT; 

ESF 

CODE; 

B8ZS 

NETWORK 

YELALRM; 

ENABLE 

XMIT  PRM: 

CLOCK  SOURCE: 

NETWORK 

BIT  STUFFING; 

DISABLE 

SETLBO: 

0.0 

POSITION:  MASTER 

CNTRL  PORT 

MODEM  INIT:  DISABLE 

CONFIG 

UNIT 

DATA  RATE:  9600 

ALARMS 

TRAPS:  DISABLE 

OUTPUT:  UIRbLi 

TEL  NUM:  IBUNK) 

RATE  56/64: 

64 

CHANNELS: 

CONTINUOUS 

DTE  TX  CLK: 

INTERNAL 

PORT 

START  CHAN: 

01 

#  OF  CHAN: 

02 

DATA: 

NORMAL 

CTS: 

NORMAL 

DCD: 

NORMAL 

DSR: 

NORMAL 

Figure  G.l  Adtran  TSU  configuration  menu  tree  with  settings  for  a  128  Kbps  site 
[Adtran,  94]. 
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Figure  G.2  is  the  dip-switch  configuration  of  the  Adtran  56/64  DSU.  Note  that 
the  CSU  function  is  not  required  since  the  site  is  not  receiving  the  multiple  channels 
associated  with  fi’actional  T-1  lines. 


*  *  *  *  t  t  *  t 

SWl  SW2  SW3  SW4  SW5  SW6  SW7  SW8 

Figure  G.2  Adtran  56/64  DSU  dip-switch  configuration  (56  Kbps  sites). 
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APPENDIX  H.  CISCO  2514  ROUTER  CONFIGURATION 


Chapter  VI  described  the  origin  of  the  WAN  and  LAN  configuration  parameters 
used  in  the  following  configuration  script.  The  script  is  included  as  an  example  of  the 
router  configuration  process  and  to  document  a  successful  Cisco  2514  configuration 
script.  The  site  being  documented  is  the  dual  port  LAN  of  Monterey  High  School  and  the 
Monterey  Academy  of  Oceanographic  Science  (MAOS).  In  viewing  the  script  note  that  a 
single  physical  WAN  connection  exists  on  serial  port  zero.  Two  PVC's  are  created  linking 
the  site  to  the  Monterey  County  Office  of  Education  (MCOE)  and  California  State 
University  Monterey  Bay  (CSUMB).  The  two  links  enable  Internet  access  and  Domain 
Name  Service  (DNS)  respectively. 

NOTE:  If  this  is  the  first  time  you  enter  the  Cisco  router  configuration  program 
you  Avill  automatically  get  the  global  setup  menu.  If  you  need  to  change  global  parameters 
later,  type  "setup"  while  in  the  enable  mode.  This  file  is  a  copy  of  the  initial  setup  script  of 
a  Cisco  2514  running  version  10.2  software.  Italic  script  indicates  computer  generated 
summary  information.  Capitalized  and  boldface  information  indicate  user  input.  [] 
indicates  Cisco  default  settings.  No  boldface  answer  indicates  that  the  default  settings 
enclosed  in  the  []  brackets  were  used. 

Would  you  like  to  enter  the  initial  configuration  dialog? 
[yes] 

First,  would  you  like  to  see  the  current  interface  summary? 
[yes] 


Interface 

IP-Address 

OK? 

Method 

Status 

Protocol 

E  theme  to 

unassigned 

NO 

not 

set 

up 

down 

SerialO 

unassigned 

NO 

not 

set 

down 

down 

Seriall 

unassigned 

NO 

not 

set 

down 

down 

Configuring  Global  Parameters; 

Enter  host  name  [router] :  MHS 

Enter  enable  password:  XXXXX 

Enter  virtual  terminal  password:  CISCO 
Configure  SNMP  Network  Management?  [yes] :  NO 
Configure  DECnet?  [no] : 

Configure  AppleTalk?  [no] : 

Configure  IPX?  [no] : 

Configure  Bridging?  [no] : 

Configure  IP?  [yes] : 

Configure  IGRP  routing?  [yes] : 

Your  IGRP  autonomous  System  Number  is  [1] :  11 
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Configuring  interface  parameters: 

Configuring  interface  EthernetO : 

Is  this  interface  in  use?  [yes] : 

Configure  IP  on  this  interface?  [yes] : 

IP  address  for  this  interface:  205.155.36.1 
Number  of  bits  in  subnet  field  [0] : 

Class  C  network  is  205.155.36.0,  0  subnet  bits;  mask  is 
255.255.255.0 

Configuring  interface  Ethernetl : 

Is  this  interface  in  use?  [yes] : 

Configure  IP  on  this  interface?  [yes] : 

IP  address  for  this  interface:  205.155.54.1 
Number  of  bits  in  subnet  field  [0] : 

Class  C  network  is  205.155.54.0,  0  subnet  bits;  mask  is 
255.255.255.0 

Configuring  interface  SerialO : 

Is  this  interface  in  use?  [yes] : 

Configure  IP  on  this  interface?  [yes] :  NO 

Configuring  interface  Seriall: 

Is  this  interface  in  use?  [no] : 

The  following  configuration  command  script  was  created: 

hostname  mhs 

enable  password  XXXXX 

line  vty  0  4 

password  cisco 

no  snitp-seirver 

j 

no  decnet  routing 
no  appletalk  routing 
no  ipx  rou ting 
no  bridge  1 
ip  routing 

I 

interface  EthernetO 

ip  address  205.155.36.1  255.255.255.0 
no  mop  enabled 

I 

interface  Ethernetl 
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ip  address  205.155.54.1  255.255.255.0 
no  mop  enabled 

j 

interface  SerialO 
no  ip  address 
no  mop  enabled 

I 

interface  Seriall 

shutdown 

no  ip  address 

I 

router  igrp  11 
network  205.155.36.0 
network  205.155.54.0 

j 

end 

Use  this  configuration?  [yes/no] :  YES 
###### [OK] 

Use  the  enabled  mode  'configure'  command  to  modify  this 

configuration. 

mmhsttCONFIG  T 

Enter  configuration  commands,  one  per  line.  End  with 
CNTL/Z. 

mhs{config)#IP  NftME-SERVER  205.155.43.2 
mhs (config) #INT  S  0 
mhs{config-if)#ENCAP  FRAME-RELAY 
mhs(config-if)#FRAME-RELA.Y  LMI-TYPE  ANSI 
mhs (config-if ) #INT  S  0.1  POINT-TO-POINT 

mhs(config-subif)#IP  ADDR  198.189.239.22  255.255.255.252 

mhs(config-subif)#FRAME-RELAY  INTERFACE-DLCI  906  BROADCAST 

mhs  (config-stibif )  #ROUTER  IRPG  11 

mhs ( conf ig-rou ter ) #NETWORK  198.189.239.0 

mhs (config-router) #INT  S  0.1 

mhs ( config -subif) #DESCR  ?  LINE  Up  to  80  characters 
describing  this  interface 

mhs ( conf ig-subif)#descr  MHS  2  MCOE  CKT#50YBQQ2753 05-001, 
DLCI  906 

mhs (conf ig-subif) #INT  S  0.2  POINT-TO-POINT 
mhs { conf ig-subif)#IP  ADDR  198.189.239.106  255.255.255.252 
mhs (conf ig-subif )#FRAME-RELAY  INTERFACE-DLCI  806  BROADCAST 
mhs (conf ig-subif ) #INT  S  0.2 
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mhs (config-subif ) #DESCR  ?  LINE  Up  to  80  characters 
describing  this  interface 

mhs (config-subif) #descr  MHS  2  CSU  CKT#50YBQQ2753 05-001,  DLCI 
806 

mhs  (config-subif ) 

mhs#%SYS-5-C0NFIG_I :  Configured  from  console  by  console 
mhs#WR  T 

#####Current  configuration: 

I 

version  10.2 

I 

hostname  mhs 

I 

enable  password  XXXXX 
! 

interface  EthernetO 

ip  address  205.155.36.1  255.255.255.0 
no  mop  enabled 

I 

Interface  Ethernet I 

ip  address  205.155.54.1  255.255.255.0 
no  mop  enabled 

I 

interface  SerialO 
no  ip  address 
encapsulation  frame-relay 
frame-relay  Imi-type  ansi 

t 

interface  SerialO. 1  point-to-point 

description  MHS  2  MCOE  CKT#50YBQQ275305-001,  DLCI  906 
ip  address  198.189.239.22  255.255.255.252 
frame-relay  inter face-dlci  906  broadcast 

t 

interface  SerialO . 2  point-to-point 

description  MHS  2  CSU  CKT#50YBQQ275305-001,  DLCI  806 
ip  address  198.189.239.106  255.255.255.252 
frame-relay  interface-dlci  806  broadcast 

I 

interface  Seriall 
no  ip  address 
shutdown 

I 

router  igrp  11 
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network  205.155.36.0 
network  205.155.54.0 
network  198.189.239.0 

I 

ip  name-server  205 . 155 . 43 .2 

I 

line  con  0 
line  aux  0 
line  vty  0  4 
password  cisco 
login 
! 

end 

inhs#WR######[OK] 

mhstEXIT 
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APPENDIX  1.  MONTEREY  BAYNET  TOPOLOGY 


The  following  Figures  1. 1  and  1.2  are  a  graphical  depiction  of  the  Monterey 
BayNet  topology  as  designed  in  Chapter  VI.  The  images  were  created  by  Jim  Warner  of 
the  University  of  California  Santa  Cruz  using  a  Computer  Aided  Design  (CAD)  program. 
Updates  to  the  images  are  presently  available  for  anonymous  file  transfer  fi-om; 
ftp.ucsc.edu/MBay-net/  or  monterey.kl2.ca.us/pub/ the  files  are  mmediMbaynet-Mont.ps 
and  Mbaynet-SC.ps.  The  '.ps'  file  extension  indicates  that  the  file  is  stored  in  PostScript 
format  and  requires  a  PostScript  viewer  or  printer  to  display.  Corresponding  Universal 
Resource  Locators  (URLs)  for  these  diagrams  are. 

• ftp: //ftp.  ucsc.  edu/MBay-net/Mbaynet-Mont.ps. 

• ftp: //ftp.  ucsc.  edu/MBay-net/Mbaynet-SC. ps. 

• ftp://monterey.  kl2.  ca.  us/pub/Mbaynet-Mont.ps. 

• ftp://monterey.  kl2.  ca.  us/pub/Mbaynet-SC. ps. 

The  large  circles  in  the  diagram  represent  each  of  the  sites.  Each  of  them  have  a 
unique  class  C  address  from  the  205.1 55. Y.  block.  The  COEs  are  presented  in  the  middle 
of  the  diagrams.  At  the  top  of  each  diagram  is  the  Internet  provider  connection  point,  San 
Francisco  State  (SFSU)  in  Santa  Cruz  and  CSU  Monterey  Bay  (CSUMB)  in  Monterey. 
The  heavy  double  line  between  SFSU  and  CSUMB  represents  the  CSUnet  backbone 
which  connects  each  WAN  (in  addition  to  many  other  CSUnet  sites)  across  the  LATA 
boundary  using  Sprint  as  the  primary  long  distance  carrier. 

Each  line  connecting  two  large  circles  is  a  PVC.  The  PVC  is  mapped  to  PacBell's 
assigned  DLCI  indicated  by  the  smaller  circle  on  the  line.  At  each  end  of  the  PVC  are  the 
IP  addresses  which  allow  DLCI  mapping.  The  Santa  Cruz  DLCI  IP  addresses  are  all  from 
the  198. 189.240.Z  block;  Monterey  from  198.189.239.Z. 

Note  that  the  K-8  sites  are  forced  to  transit  via  the  COEs  in  order  to  reach  the 
Internet.  High  schools  have  direct  access  to  the  Internet  provider  without  passing  through 
the  COE.  See  Chapter  VI  Section  G  for  more  details  on  this  design  decision. 
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IS7.14317&E  13714&t76,J 


Figure  LI  Monterey  BayNet  in  Monterey  County 
Available  at  ftp://ucsc.edu/MBay-net/Mbaynet-Mont.ps. 
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CAT?  HQ^»ori{  ind  T^tecouM 


This  T-1  link  IS  port  of  the  csu-Net  bRckioone 


Figure  L2  Monterey  BayNet  in  Santa  Cruz  County 
Available  at  ftp  J/ucsc.edu/MBay-netMbaynet-SC.ps. 

107 


108 


APPENDIX  J.  COMMITTED  INFORMATION  RATE  (CIR)  MATRIX 


Chapter  VI  describes  the  WAN  topology  design  process.  Tables  J.  1  and  J.2  are 
excerpted  from  PacBell's  final  work  request  inputs  [Bellamy,  95],  PacBell  stated  that  a 
approximately  two  hundred  percent  over-commitment  of  the  Frame  Relay  lines  would  be 
allowed  [Bellamy,  95],  The  rate  of  over  commitment  is  a  negotiable  value.  Committed 
Information  Rate  (CIR)  is  PacBell's  method  of  guaranteeing  a  worst  case  data  exchange 
rate.  This  is  of  particular  interest  to  customers  who  purchase  full  T-1  connectivity.  On  a 
full  T-1  line  Frame  Relay  the  data  is  guaranteed  to  flow  at  the  CIR  and  has  the  ability  to 
"burst"  to  fiill  T-1  speeds  where  the  traffic  permits.  In  the  case  of  the  Santa  Cruz  COE 
the  CIR  on  DLCI 190  is  512  Kbps.  At  any  given  moment  the  actual  data  exchange  rate 
between  SFSU  and  SCCOE  will  be  some  rate  between  512  Kbps  and  1.5  Mbps 
depending  upon  traffic  conditions  at  the  switch.  The  CIR  for  each  site  is  of  less  critical 
importance.  The  Frame  Relay  service  can  not  "burst"  to  higher  levels  on  a  partial  T-1  line 
because  the  unused  channels  are  physically  blanked  out. 

The  total  CIR  in  each  LATA  can  be  calculated  by  summing  the  CIR  values  and 
comparing  the  total  with  the  physical  line  speed  of  the  host.  The  sum  of  all  Santa  Cruz 
County  Office  of  Education  CIRs  is  2.752  Mbps.  Note  that  the  CIR  on  DLCI  190  is  only 
included  once  since  this  is  physically  the  same  PVC.  Line  speed  at  the  Santa  Cruz  COE  is 
1.5  Mbps.  Comparison  shows  that  the  SCCOE  line  is  179.2%  overcommitted.  If  every 
SCCOE  site  tried  to  connect  to  the  SCCOE  at  the  same  time  some  sites  would  experience 
delays.  Fortunately  many  sites  have  an  alternate  route  to  the  Internet  which  does  not  pass 
through  the  SCCOE  and  thus  reduces  the  opportunity  for  congestion  at  the  SCCOE. 

Monterey  County  Office  of  Education  has  an  even  higher  rate  of  over  subscription. 
The  total  of  all  CIRs  is  3.256.  This  yields  a  220  percent  oversubscription  rate.  Both 
counties  are  at  the  point  where  additional  site  connections  will  require  the  purchase  of  an 
additional  T-1  line  at  the  COE. 
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Location 


Santa  Cruz  County  OflQce  of 

Education 

1.536 

.512 

San  Francisco  State  University 

1.536 

.512 

University  of  California  Santa 

Cruz 

1.536 

.384 

Cabrillo  College 

0.384 

.256 

Harbor  High  School 

0.128 

.128 

San  Lorenzo  Valley  High 

0.128 

.128 

Soquel  High  School 

0.128 

.128 

Santa  Cruz  High  School 

0.128 

.128 

Happy  VaUey  High  School 

0.128 

.128 

Minte  White  Elementty  School 

0.128 

.128 

Ohlone  SchoolTPajaro  Valley 

District 

0.128 

.128 

De  La  Veaga  School 

0.056 

.056 

Branciforte  Elementary  School 

0.056 

.056 

Watsonville  High  School 

0.128 

.128 

Alianza  School 

0.056 

.056 

Brook  Knoll  Elementary  School 

0.056 

.056 

Rio  Del  Mar  Elementary  School 

0.056 

.056 

Valencia  Elementary  School 

0.056 

.056 

Aptos  Ffigh  School 

0.128 

.128 

Santa  Cruz  Garden  Elementary 

0.056 

.056 

Del  Mar  Middle  School 

0.056 

.056 

COE 

SFSU 

AddI 

Install 

DLCI 

DLCI 

DLCI 

Date 

03/13/95 


03/14/95 


230  03/15/95 


03/16/95 


03/24/95 


03/24/95 


03/30/95 


04/05/95 


04/10/95 


04/14/95 


04/20/95 


04/26/95 


05/01/95 


05/05/95 


05/05/95 


05/10/95 


05/16/95 


05/22/95 


05/24/95 


05/26/95 


12/95 


Table  J.l  Santa  Cruz  County  OfiBce  of  Education  Committed  Information  Rate  (CIR) 
matrix  excerpted  from  PacBell's  final  work  request  inputs  [Bellamy,  95], 
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Location 

Line 

Speed 

CIR 

Mbps 

COE 

DLCI 

CSUMB 

DLCI 

Install 

Date 

1 

Monterey  County  Office  of  Education 

1.536 

.512 

890 

03/07/95 

2 

California  State  University  Monterey  Bay 

1.536 

.512 

890 

03/14/95 

3 

United  States  Naval  Postgraduate  School 

0.128 

.128 

902 

802 

03/09/95 

4 

Seaside  High  School  Library 

0.128 

.128 

903 

803 

03/10/95 

5 

Monterey  Bay  Technology  Education 

Center 

0.384 

.384 

904 

804 

03/22/95 

6 

Moss  Landing  Marine  Laboratories 

0.128 

.128 

905 

805 

04/04/95 

7 

Monterey  High  School 

0.128 

.128 

906 

806 

04/03//95 

8 

North  Monterey  County  High  School 

0.128 

.128 

907 

807 

04/07/95 

9 

Monterey  Bay  National  Marine  Sanctuary^ 

0.128 

.128 

908 

808 

04/12/95 

10 

Monterey  County  Free  Libraries 

0.128 

.128 

909 

809 

04/18/95 

11 

El  Sausel  Middle  School 

0.128 

.128 

910 

04/24/95 

12 

Manzanita  Elementary  School 

0.128 

.128 

911 

05/24/95 

13 

La  Mesa  Elementary  School 

0.128 

.128 

912 

05/03/95 

14 

Main  Street  School 

0.128 

.128 

913 

03/23/95 

15 

Del  Rey  Elementary  School 

0.128 

.128 

914 

05/12/95 

16 

Cypress  Continuation  School 

0.128 

.128 

915 

05/18/95 

17 

Marshall  Elementary  School 

0.128 

.128 

916 

04/28/95 

18 

Mission  Pari:  Elementary  School 

0.056 

.056 

917 

05/30/95 

19 

Instructional  Media  Center  (IMC) 

0.128 

.128 

918 

06/05/95 

20 

Monterey  Peninsula  College  Library 

0.128 

.128 

919 

819 

06/09/95 

21 

Monterey  Institute  for  Research  in 

Astronomy 

0.128 

.128 

920 

820 

6/14/95 

22 

Monterey  Public  Library 

0.128 

.128 

921 

6/16/95 

Table  J.2  Monterey  County  Office  of  Education  Committed  Information  Rate  (CIR) 
matrix  excerpted  from  PacBell's  final  work  request  inputs  [Bellamy,  95], 


APPENDIX  K.  OBTAINING  AN  IP  NETWORK  NUMBER 


Chapter  VI  discussed  the  requirement  for  Internet  Protocol  (IP)  network  number 
registration  with  the  InterNIC.  The  registration  template  is  presented  here  for  reference. 
The  Monterey  BayNet  block  of  IP  addresses  were  registered  and  issued  by  the  Internet 
provider  (CSUnet).  The  Universal  Resource  Locator  (URL)  for  the  latest  copy  of  this 
registration  template  is ftp://rs.intemic.net/templates/intemet-number-template.txt 

[  templates/internet-number-template . txt  ]  [  04/94  ] 

This  form  must  be  completed  as  part  of  the  application 
process  for  obtaining  an  Internet  Protocol  (IP)  Network 
Number.  To  obtain  an  Internet  number,  please  provide  the 
following  information  on-line,  via  electronic  mail,  to 
HOSTMA.STER@INTERNIC.NET.  If  electronic  mail  is  not 
available  to  you,  please  mail  hardcopy  to: 

Network  Solutions 
InterNIC  Registration  Services 
505  Huntmar  Park  Drive 
Herndon,  VA  22070 
--  OR  -- 

FAX  to  (703)  742-4811 

Once  Registration  Services  receives  your  completed 
application  we  will  send  you  an  acknowledgement,  via 
electronic  or  postal  mail. 

NOTE:  This  application  is  solely  for  obtaining  a  legitimate 
IP  network  number  assignment.  If  you're  interested  in 
officially  registering  a  domain  please  complete  the  domain 
application  found  in  templates /domain- template . txt .  If  FTP 
is  not  available  to  you,  please  contact 

HOSTMASTER@INTERNIC.NET  or  phone  the  NIC  at  (800)  444-4345 
(703)  742-4777  for  further  assistance. 

YOUR  APPLICATION  MUST  BE  TYPED. 

1)  If  the  network  will  be  connected  to  the  Internet,  you 
must  provide  the  name  of  the  governmental  sponsoring 
organization  or  commercial  service  provider,  and  the  name, 
title,  mailing  address,  phone  niomber,  net  mailbox,  and  NIC 
Handle  (if  any)  of  the  contact  person  (POC)  at  that 
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organization  who  has  authorized  the  network  connection. 

This  person  will  serve  as  the  POC  for  administrative  and 
policy  questions  about  authorization  to  be  a  part  of  the 
Internet.  Examples  of  such  sponsoring  organizations  are: 
DISA  DNS,  The  National  Science  Foundation  (NSF) ,  or  similar 
government,  educational  or  commercial  network  service 
providers . 

NOTE:  IF  THE  NETWORK  WILL  NEVER  BE  CONNECTED  TO  THE 
INTERNET,  PLEASE  UTILIZE  THE  ADDRESS  SPACE  RESERVED  FOR  NON- 
CONNECTED  NETWORKS  THAT  IS  SPECIFIED  IN  RFC  1597.  IF  YOU 
INTEND  TO  CONNECT  THIS  NETWORK  TO  THE  INTERNET  BUT  HAVE  NOT 
YET  CHOSEN  A  SERVICE  PROVIDER,  LEAVE  THIS  SECTION  BLANK,  BUT 
INDICATE  THE  APPROXIMATE  DATE  OF  YOUR  INTERNET  CONNECTION  IN 
SECTION  9  OF  THIS  TEMPLATE.  IF  YOU  INTEND  TO  CONNECT  TO  THE 
INTERNET  AND  HAVE  ALREADY  CHOSEN  A  PROVIDER,  YOU  ARE 
REQUIRED  TO  SUBMIT  THIS  REQUEST  TO  YOUR  SERVICE  PROVIDER  FOR 
PROCESSING.  SERVICE  PROVIDERS  ARE  ALLOCATED  BLOCKS  OF 
ADDRESSES  TO  SUPPORT  THE  NETWORKING  NEEDS  OF  THEIR 
CUSTOMERS.  THIS  PROCEDURE  WILL  ENSURE  THAT  THE  NUMBER  OF 
ENTRIES  ADDED  TO  THE  INTERNET  ROUTING  TABLES  IS  KEPT  TO  A 
MINIMUM,  AND  CIDR  IS  USED  AS  EFFICIENTLY  AS  POSSIBLE.  THE 
ABOVE  PROCEDURES  PERTAIN  EXCLUSIVELY  TO  REQUESTS  FOR  CLASS  C 
ADDRESS (ES) . 

la.  Sponsoring  Organization: 

lb.  Contact  name  (Lastname,  Firstname) : 

lc .  Contact  title: 

ld.  Mail  Address  : 

le .  Phone  : 

lf .  Net  mailbox  : 

lg.  NIC  handle  (if  known) : 

2)  Provide  the  name,  title,  mailing  address,  phone  number, 
and  organization  of  the  technical  Point-of-Contact  (POC) . 

The  on-line  mailbox  and  NIC  Handle  (if  any)  of  the  technical 
POC  should  also  be  included.  This  is  the  POC  for  resolving 
technical  problems  associated  with  the  network  and  for 
updating  information  about  the  network.  The  technical  POC 
may  also  be  responsible  for  hosts  attached  to  this  network. 

2a.  NIC  handle  (if  known) : 

2b.  Technical  POC  name  (Lastname,  Firstname) : 
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2c.  Technical  POC  title: 
2d.  Mail  address  : 

2e.  Phone  : 

2f.  Net  Mailbox  : 


3)  Supply  the  SHORT  mnemonic  name  for  the  network  (up  to  12 
characters) .  This  is  the  name  that  will  be  used  as  an 
identifier  in  internet  name  and  address  tables.  The  only 
special  character  that  may  be  used  in  a  network  name  is  a 
dash  ( - ) .  PLEASE  DO  NOT  USE  PERIODS  OR  UNDERSCORES .  The 
syntax  XXXX.com  and  XXXX.net  are  not  valid  network  naming 
conventions  and  should  only  be  used  when  applying  for  a 
domain . 

3 .  Network  name : 

4)  Identify  the  geographic  location  of  the  network  and  the 
organization  responsible  for  establishing  the  network. 

4a.  Postal  address  for  main/headquarters  network 

site : 

4b.  Name  of  Organization: 


5)  Question  #5  is  for  MILITARY  or  DOD  requests,  ONLY. 

If  you  require  that  this  connected  network  be  announced  to 
the  NSFNET  please  answer  questions  5a,  5b,  and  5c.  IF  THIS 
NETWORK  WILL  BE  CONNECTED  TO  THE  INTERNET  VIA  MILNET,  THIS 
APPLICATION  MUST  BE  SUBMITTED  TO  HOSTMASTER@MIC.DDN.MIL  FOR 
REVIEW/ PROCESSING . 

5a.  Do  you  want  MILNET  to  announce  your  network  to  the 
NSFNET?  (Y/N) : 

5b.  Do  you  have  an  alternate  connection,  other  than  MILNET, 
to  the  NSFNET?  (please  state  alternate  connection  if  answer 
is  yes) : 

5c.  If  you've  answered  yes  to  5b,  please  state  if  you  would 
like  the  MILNET  connection  to  act  as  a  backup  path  to  the 
NSFNET?  (Y/N) : 
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6)  Estimate  the  size  of  the  network  to  include  the  number  of 
hosts  and  subnets /segments  that  will  be  supported  by  the 
network.  A  "host”  is  defined  as  any  device  (PC,  printer 
etc.)  that  will  be  assigned  an  address  from  the  host  portion 
of  the  network  nxamber.  A  host  may  also  be  characterized  as  a 
node  or  device . 

Host  Information 


6a.  Initially: 

6b.  Within  one  year: 

6c .  Within  two  years : 
6d.  Within  five  years: 

Subnet/Segment  Information 


6e.  Initially: 

6f.  Within  one  year: 

6g .  Within  two  years : 

6h.  Within  five  years: 

7)  Unless  a  strong  and  convincing  reason  is  presented,  the 
network  (if  it  qualifies  at  all)  will  be  assigned  a  single 
class  C  network  number.  If  a  class  C  network  number  is  not 
acceptable  for  your  purposes,  you  are  required  to  submit 
substantial,  detailed  justification  in  support  of  your 
requirements . 

7.  Reason: 

8)  Networks  are  characterized  as  being  either  Research, 
Educational,  Government  -  Non  Defense,  or  Commercial.  Which 
type  is  this  network? 

8.  Type  of  network: 

9)  What  is  the  purpose  of  the  network? 

9 .  Purpose : 

RECOMMENDED  READING  (available  via  anonymous  FTP  from 
DS.INTERNIC.NET  (198.49.45.10),  or  call  1-800-444-4345 
option  #1) 
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APPENDIX  L.  MONTEREY  BAYNET  DOMAIN  NAME  SERVICE 


The  following  Monterey  BayNet  sites  have  domain  name  service  (DNS)  entries  as 
indicated  below.  Most  individual  school  sites  do  not  presently  operate  an  Internet  server. 
In  the  interim  these  DNS  entries  Avill  be  linked  to  their  respective  county  ofBce  of 
education  (205.155.8.2  and  205.155.43.2).  When  the  site  has  established  an  Internet 
server  the  DNS  will  be  corrected  to  reflect  the  IP  address  of  that  server.  The  registration 
process  was  performed  as  per  Appendix  M. 

In  designing  the  names  balance  needs  to  be  found  between  clear  descriptions  and 
unclear  acronyms.  Note  that  DNS  names  are  not  case  sensitive.  Variations  on  a  theme 
with  upper  and  lower  case  letter  will  not  work.  Another  consideration  discovered  in 
Monterey  BayNet  is  that  some  seemingly  appropriate  acronyms  have  inappropriate 
connotations  in  a  foreign  language.  In  a  largely  bi-lingual  population  these  considerations 
are  vital.  The  final  approval  of  DNS  entries  must  reside  with  the  site  residents. 

SANTA  CRUZ  COUNTY  LANs  &  DNS 

Ethernet  Site  DNS  Name 

205.155.1  Harbor  High  School  harborhs.santacruz.kl2. ca  ns 

205. 155.2  San  Lorenzo  Valley  High  slvhs.santacruz.kl2.ca.us 

205.155.3  Watsonville  High  School  whs.santacruz.kl2.ca.us 

205.155.4  Aptos  IBgh  School  aptoshs.santacruz.kl2.ca.us 

205.155.5  Santa  Cruz  High  School  santacruzhs.santacruz.kl2.ca.us 

205.155.6  Soquel  High  School  soquelhs.santacruz.kl2.ca.us 

205.155.7  Cabrillo  College  cabrillo.cc.ca.us 

205. 1 55.8  Santa  Cruz  County  Office 

ofEducation  sccoe.santacruz.kl2.ca.us 

205.155.9  Nfintie  White  Elementary  mw.santacruz.kl2.ca.us 

205.155.10  Alianza  Elementary  alianza.santacruz.kl2.ca.us 

205.155.11  Branciforte  Elementary  b40elem.santacruz.kl2.ca.us 

205. 155. 12  Santa  Cruz  Garden  Elem  scg.santacruz.kl2.ca.us 

205.155.13  Brook  Knoll  Elementary  brknoll.santacruz.kl2.ca.us 

205.155.14  Ohlone  School  ohlone.santacruz.kl2.ca.us 

205. 155.15  De  La  Veaga  School  delave.santacruz.kl2.ca.us 

205.155.16  Del  Mar  Middle  School  delmar.santacruz.kl2.ca.us 

205.155.17  Valencia  Elementary  Valencia. santacruz.kl2.ca.us 

205.155.18  Rio  Del  Mar  Elementary  riodelmar.santacruz.kl2.ca.us 

205.155.19  Happy  Valley  School  happyvalley.santacruz.kl2.ca.us 
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MONTEREY  COUNTY  LANs  &  DNS 


Ethernet 

205.155.32 

205.155.33 

205.155.34 

205.155.35 

205.155.36 

205.155.37 

205.155.38 

205.155.39 

205.155.40 

205.155.41 

205.155.42 

205.155.43 

205.155.44 

205.155.45 

205.155.46 

205.155.47 

205.155.48 

205.155.49 

205.155.50 

205.155.51 

205.155.52 


205.155.53 

205.155.54 

205.155.55 


Site 

Naval  Postgraduate  School 
Education  Access  Gateway 
Seaside  High  School 
Monterey  Bay  Technology 
Education  Center 
Moss  Landing  Marine  Lab 
Monterey  High  School 
North  Monterey  County 
High  School 
Monterey  Bay  National 
Marine  Sanctuary 
Monterey  County  Free 
Libraries 

Monterey  Peninsula 
College  Library 
Monterey  Institute  for 
Research  in  Astronomy 
Monterey  Public  Library 
Monterey  County 
Office  of  Education 
El  Sausel  Middle  School 
Manzanita  Elementary 
La  Mesa  Elementary 
Main  Street  School 
Del  Rey  Elementary 
Cypress  Continuation 
Marshall  Elementary 
(lower  campus) 

Mission  Park  Elementary 
Monterey  Peninsula  Unified 
School  District  Instructional 
Media  Center 

Monterey  County  Office  of 
Education  (secure) 
Monterey  Academy  of 
Oceanographic  Science 
Fitch  Middle  School 


DNS  Name 


edac.nps.navy.mil 

shs.monterey.kl2.ca.us 

mbtec.monterey.kl  2.  ca.us 
mlml.calstate.edu 
nihs.monterey.kl2. ca.us 

nmhs.  monterey .  k  1 2 .  ca.us 

mbnms.nos.noaa.gov 

mcfl.  monterey .  lib.  ca.  us 

mpc.cc.ca.us 

mira.org 

monterey.lib.ca.us 

bill.monterey.  k  1 2.  ca.us 
elsaus.  monterey  .k  1 2 .  ca.us 
mz.  monterey .  k  1 2 .  ca.  us 
Imesa.  monterey  .k  1 2 .  ca.  us 
mainst .  monterey.k  1 2 .  ca.us 
drey,  monterey.  k  1 2.  ca.us 
cyp.monterey.kl2.ca.us 

marsh,  monterey.k  1 2 .  ca.us 
mnpk.  monterey.  k  1 2 .  ca.us 


imc.monterey.kl2.ca.us 

mcoe.  monterey  .k  1 2.  ca.us 

maos.monterey.kl2. ca.us 
fitch.monterey.kl2.ca.us 
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APPENDIX  M.  INSTRUCTIONS  FOR  THE  US  DOMAIN  TEMPLATE 

A.  SUMMARY 

Chapter  VI  discussed  the  requirement  for  domain  registration.  Monterey  BayNet 
registered  with  CSUnet,  the  Internet  provider.  Portions  of  the  registration  template  are 
presented  here  for  reference  and  to  compare  with  the  completed  Monterey  BayNet 
registration  forms  which  follow.  The  Universal  Resource  Locator  (URL)  for  the  latest 
copy  of  the  registration  form  is  ftp://rs.intemic.net/templates/domain-template.txt . 

B.  TEMPLATE 

INSTRUCTIONS  FOR  THE  US  DOMAIN  TEMPLATE  [1/95] 

(Do  not  use  this  template  for:  COM,  EDU,  NET,  ORG,  GOV)* 
************************************************************ 

To  register  a  host  in  the  US  domain,  the  US  Domain  Template 
must  be  sent  to  the  US  Domain  Registrar  (US-Domain@ISI.EDU) 
or  contact  of  a  delegated  zone. 

Email :  US-Domain@ISI .  EDU 

Fax:  310-823-6714 

Phone:  310-822-1511 
To :  US  Domain  Registrar 

USC/Information  Sciences  Institute 

4676  Admiralty  Way,  Marina  del  Rey,  CA  90292 

(1)  PLEASE  SPECIFY  WHETHER  THIS  IS  A  NEW  APPLICATION, 
MODIFICATION  TO  AN  EXISTING  REGISTRATION,  OR  DELETION. 

(2)  THE  NAME  OF  THE  DOMAIN.  This  is  the  name  that  will  be 
*  used  in  tables  and  lists  associating  the  domain  with  the 

domain  server  addresses . 


TABLE:  US  DOMAIN  NAMING  STRUCTURE 


<host>.<locality>.<state-code>.US  =  locality  based  names 
<host>.CL<locality>.<state-code>.US  =  locality;  city  gov.  agency 
<host>.CO.<locality>.<state-code>.US=  locality;  county  gov.  agency 
<school>.<district>.K12.<state-code>.US  =  K  thru  12th  grade 
<school>.PVT.K12.<state-code>.US  =  private  K  thru  12th  grade 
<school>.<locality>.<state-code>.US  =  locality  opt;for  PVT  Sch 
<school>.CC.<state-code>.US  =  community  colleges 
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<school>.TEC  <state-code>.US  =  technical  or  vocational  schools 
<Iibrary-nanie>.LIB.<state-code>.US  =  libraries  (Cl,  CO,  State,PVT) 
<State-agency>.STATE.<state-code>.US  =  state  government  agencies 
<org-name>.GEN.<state-code>.US  =  statewide  assoc,clubs,BBs's 
<org-name>.MUS.<state-code>.US  =  museums 
<org-name>.COG  <state-code>.US  =  councils  of  governments 
<org-name>.DST  <state-code>.US  =  regional  agencies  or  districts  (not  gov't  &  larger 
than  city  or  county) 

<federal-agency>.FED.US  =  federal  government  agencies 

<org-name>.DNI.US  =  distributed  national  institutes  (research,  educational,  cultural) 
<org-name>.ISA.US  =  interstate  authority  (joint  gov't  authorities  -  multistate) 

Domain  Name  Example:  networthy .santa-clara.ca.us 

(3)  THE  NAME  OF  THE  ENTITY  REPRESENTED,  THAT  IS, 
ORGANIZATION  BEING  NAMED.  For  example:  The  Networthy 
Corporation,  not  the  name  of  the  Network  Service  Provider  or 
organization  submitting  the  request. 

(4)  PLEASE  DESCRIBE  THE  DOMAIN  BRIEFLY. 

For  exait^le:  The  Networthy  Corporation  is  a  consulting 
organization  of  people  working  with  UNIX  and  the  C  language 
in  an  electronic  networking  environment.  It  sponsors  two 
technical  conferences  annually  and  distributes  a  bimonthly 
newsletter . 

(5)  THE  DATE  YOU  EXPECT  THE  DOMAIN  TO  BE  FULLY  OPERATIONAL. 
For  every  registration,  we  need  both  the  administrative 

and  the  technical  contacts  of  a  domain  (questions  6  &  7)  and 
we  MUST  have  ^  network  mailbox  for  each.  If  you  have  a  NIC 
handle  (a  unique  NIC  database  identifier)  please  enter  it. 
(If  you  don't  know  what  a  NIC  handle  is  leave  it  blank) . 

Also  the  title,  mailing  address,  phone  number,  organization, 
and  network  mailbox. 

(6)  THE  NAME  OF  THE  ADMINISTRATIVE  HEAD  OF  THE 
"ORGANIZATION" .  The  administrator  is  the  contact  point  for 
administrative  and  policy  questions  about  the  domain.  The 
Domain  administrator  should  work  closely  with  the  personnel 
he  has  designated  as  the  "technical  contact"  for  his  domain. 
In  this  example  the  Domain  Administraror  would  be  the 
Administrator  of  the  Networty  Corporation,  not  the 
Administrator  of  the  organization  running  the  nameserver 
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(unless  it  is  the  same  person) . 


(7)  THE  NAME  OF  THE  TECHNICAL  AND  ZONE  CONTACT.  The 
technical  and  zone  contact  handles  the  technical  aspects  of 
maintaining  the  domain's  name  server  and  resolver  software, 
and  database  files.  He  keeps  the  name  server  running.  More 
than  likely,  this  person  would  be  the  technical  contact 
running  the  primary  nameserver. 

icic'k-kir-kicicicicicic-kicic’k‘kic±ic-krkicic‘kicicic±ii:'k'k'k'k'k-k'k’kicirii:icicic±icii:i(:icicicic-kicicicicrkicic 

PLEASE  READ:  There  are  several  types  of  registrations: 

(a)  Delegation  (i.e.,  a  portion  of  the  US  Domain  name 
space  is  given  to  an  organization  running  nameservers  to 
support  that  branch;  For  example,  K12.TX.US,  for  all  K12 
schools  in  Texas).  For  (a)  answer  questions  8  and  9. 

(b)  Direct  Registration  of  an  IP  Host.  For  (b)  answer 
question  10. 

(c)  Direct  Registration  of  a  non-IP  Host.  For  (c)  answer 
question  11  and  12 . 

************************************************************ 
QUESTIONS  FOR  DELEGATIONS 

(8)  PRIMARY  SERVER  Information.  It  is  required  to  supply 
both  the  Contact  information  as  well  as  hardware /software 
information  of  the  primary  nameserver. 

(9) *  SECONDARY  SERVER  Infoimiation .  It  is  required  to  supply 
the  hardware  and  software  information  of  all  secondary 
nameservers .  Domains  must  provide  at  least  two  independent 
servers  that  provide  the  domain  service  for  translating 
names  to  addresses  for  hosts  in  this  domain.  If  you  are 
applying  for  a  domain  and  a  network  number  assignment 
simultaneously  and  a  host  on  your  proposed  network  will  be 
used  as  a  server  for  the  domain,  you  must  wait  until  you 
receive  your  network  number  assigment  and  have  given  the 
server (s)  a  net-address  before  sending  in  the  domain 
application.  Establishing  the  servers  in  physically  separate 
locations  and  on  different  PSNs  and/or  networks  is  strongly 
recommended . 
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NOTE:  For  those  applicants  not  able  to  run  nameservers ,  or 
for  non-IP  hosts  the  Name  Server  information  is  not 
applicable.  (See  #10  and  #11). 


QUESTION  FOR  DIRECT  IP  HOSTS  (If  you  answered  8&9  do  not 
answer  10,11,12). 


(10)  WHAT  DOMAIN  NAME  SYSTEM  (DNS)  RESOURCE  RECORDS  (RR)  AND 
VALUES  ARE  TO  BE  ENTERED  FOR  YOUR  IP  HOST  (MUST  HAVE  AN  A 
RECORD) . 


Example:  RRs  for  an  INTERNET  hosts. 


(a)  DOMAIN  NAME  (required) . . . 

(b)  IP  ADDRESS  (required) . . . . 

(C)  HARDWARE  (opt) . 

(d)  OPERATING  SYS  (opt) . 

(e)  WKS  (opt) . 

(ftp) 

(f )  MX  (opt) . 


Networthy . Santa-Clara . CA . US . 
A  128.9.3.123 
SUN-3 /no 
UNIX 

128.9.3.123.  UDP  (tftp)  TCP 
10  RELAY.ISI.EDU. 


It  is  your  responsibility  to  see  that  an  IN-ADDR  pointer 
record  is  entered  in  the  DNS  database.  (For  internet  hosts 
only) .  Contact  the  administrator  of  the  IP  network  your 
host  is  on  to  have  this  done.  The  US  Domain  administration 
does  not  administer  the  network  and  cannot  make  these 
entries  in  the  DNS  database. 


QUESTIONS  FOR  NON-IP  HOSTS  (such  as  UUCP) . 


Many  applicants  have  hosts  in  the  UUCP  world.  Some  are  one 
hop  away,  some  two  and  three  hops  away  from  their  "Internet 
Forwarder",  this  is  acceptable.  What  is  inportant  is 
getting  an  Internet  host  to  be  your  forwarder.  If  you  do 
not  already  have  an  Internet  forwarder,  there  are  several 
businesses  that  provide  this  service  for  a  fee,  (see  RFC 
1359  -  Connecting  to  the  Internet  What  Connecting 
Institutions  Should  Anticipate,  ACM  SIGUCCS,  August  1992) . 
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Sometimes  local  colleges  in  your  area  are  already  on  the 
Internet  and  may  be  willing  to  act  as  an  Internet  Forwarder. 
You  would  need  to  work  this  out  with  the  systems 
administrator.  We  cannot  make  these  arrangements  for  you. 

(11)  INTEENET  FORWARDING  HOST  INFORMATION 

(lla)  What  is  the  name  of  your  Internet  forwarding  host? 

For  example:  The  host  Yacht-Club. MDR.CA. US  uses  UUCP  to 
connect  to  RELAY.ISI.EDU  which  is  an  Internet  host,  (i.e., 
RELAY.ISI.EDU  is  the  forwarding  host). 

(llb)  What  is  the  name  of  your  contact  person  at  fowarding 
host?  The  Administrator  of  RELAY.ISI.EDU  must  agree  to  be 
the  forwarding  host  for  Yacht-Club. MDR.CA. US,  and  the 
forwarding  host  must  know  a  delivery  method  and  route  to 
Networthy.  No  double  MXing. 

(llc)  What  is  the  mailbox  of  your  contact?  What  is  the 
mailbox  of  the  administrator  of  the  forwarding  host. 

Example:  Contact  Name . :  John  Smith 

Contact  Email . :  js@RELAY.ISI.EDU 

(12)  WHAT  DOMAIN  NAME  SYSTEM  (DNS)  RESOURCE  RECORDS  (RR)  AND 
VALUES  ARE  TO  BE  ENTERED  FOR  YOUR  NON- IP  HOST. 


Example:  RRs  for  a  NON- IP  host  (uucp) . 


(a)  DOMAIN  NAME  (required) . :  Yacht-Club. MDR.CA. US . 

(b)  HARDWARE  (opt) . . . :  SUN-3/110 

(C)  OPERATING  SYS  (opt) . :  UNIX 

(d)  MX  (required) . :  10  RELAY.ISI.EDU. 


*  NOTE:  All  K12  schools,  community  colleges/technical 
schools,  state  and  local  governmentt  agencies  are  required 
to  register  -under  the  US  domain.  Only  four  year  universities 
are  allowed  to  register  under  EDU  and  only  federal  agencies 
are  allowed  tinder  GOV.  (See  RFC  1480,  "The  US  Domain"  and 
RFC  1591,  "The  Domain  Name  System  Structure  and  Delegation" 
for  details . 
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C.  COMPLETED  DNS  REGISTRATION  FORM  FROM  THE  SANTA  CRUZ 
COUNTY  OFFICE  OF  EDUCATION 

1.  REGISTRATION  TYPE 

(N) ew  (M)odify  (D)elete..:  N 

2. *  FULLY-QUALIFIED  DOMAIN  NAME:  santacruz . kl2 . ca.us . 


3.  ORGANIZATION  INFORMATION 

3a.  Organization  Name . :  Santa  Cruz  County  Office  of 

Education 

3b.  Address  Line  1 . :  809  H  Bay  Avenue 

3b.  Address  Line  2 . : 

3c.  City.. . :  Capitola 

3d.  State . :  Ca 

3e.  Zip/Code . :  95010 

4.  DESCRIPTION  OF  ORG/DOMAIN:  The  public  schools  in 

Santa  Cruz  County 

5.  Date  Operational . :  April  15,  1995 


6.  ADMINISTRATIVE  CONTACT 
6a.  NIChandle  (if  known).. 

6b.  Whole  Name . 

6c.  Organization  Name . 

6d.  Address  Line  1 . 

6d.  Address  Line  2 . 

6e.  City . 

6f.  State . 

6g.  Zip/Code . 

6h.*  Voice  Phone . 

6i.*  Electronic  Mailbox.... 


OF  ORG/DOMAIN 
Rowland  Baker 

Santa  Cruz  County  Office  of 

Education 

809  H  Bay  Avenue 

Capitola 

Ca 

95010 

408-476-5346 
rowbake@telis . org 


7.  TECHNICAL  AND  ZONE  CONTACT 
7a.  NIChandle  (if  known)..: 

7b.  Whole  Name . :  Lucas  Fletcher 

7c.  Organization  Name . :  Santa  Cruz  County  Office  of 

Education 

7d.  Address  Line  1 . :  809  H  Bay  Avenue 

7d.  Address  Line  2 . : 

7e.  City . :  Capitola 

7f.  State . :  Ca 

7g.  Zip/Code . :  95010 

7h.*  Voice  Phone . :  408-476-7140 

7i.*  Electronic  Mailbox ....: dnsmgr@sccoe . santacruz . kl2 . ca.us 
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FILL  OUT  QUESTION  8  AND  9  FOR  DELEGATIONS  ONLY  (i.e  those 
organizations  running  nameservers  for  a  branch  of  the 
US  Domain  namespace,  for  example:  kI2 .<state>.us) . 

8.  PRIMZ^RY  SERVER:  HOSTNAME,  NETADDRESS 


NIChandle  (if  known).. 

Whole  Name . 

Organization  Name . 


Address  Line  1 ....  . 
Address  Line  2 . . . . 

City . 

State . 

Zip/Code . 

*  Voice  Phone . 

*  Electronic  Mailbox 

Hostname . 

*  IP  Address  . 

*  HARDWARE . 

*  OPERATING  SYS . 


Lucas  Fletcher 

Santa  Cruz  County  Office  of 

Education 

809  H  Bay  Avenue 

Capitola 

Ca 

95010 

408-476-7140 

dnsmgrgsccoe . santacruz . kl2 . ca . us 
ns . santacruz . kl2 . ca.us 
205.155.8.2 
Sun 

Solaris  2.4 


9.  *  SECONDARY  SERVER:  HOSTNAME,  NETADDRESS 


9a.*  Hostname . . 

9b.*  IP  Address..., 

9c .  *  HARDWARE . . 

9d.*  OPERATING  SYS, 


morris.ucsc.edu 

128.114.1.6 

Sun 

SunOS  4.1.3U 


D.  COMPLETED  DNS  REGISTRATION  FORM  FROM  THE  MONTEREY 
COUNTY  OFFICE  OF  EDUCATION 

1.  REGISTRATION  TYPE 

(N) ew  (M)odify  (D)elete..:  N 

2. *  FULLY-QUALIFIED  DOMAIN  NAME:  monterey . kl2 . ca . US . 

3.  ORGANIZATION  INFORMATION 

3a.  Organization  Name . :  Monterey  County  Office  of 

Education 

3b.  Address  Line  1 . :  901  Blanco  Circle 

3b.  Address  Line  2 . : 

3c.  City . :  Salinas 

3d.  State . :  Ca 

3e.  Zip/Code . :  93912 

4.  DESCRIPTION  OF  ORG/DOMAIN:  The  Monterey  County 

Office  of  Education  is  a 
non-profit  California 
County  government  agency 
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5. 


Date  Operational . :  April  5,  1995 

6.  ADMINISTRATIVE  CONTACT  OF  ORG/DOMAIN 
6a.  NIChandle  (if  known)..: 

6b.  Whole  Name . :  Michael  Ottmar 

6c.  Organization  Name . :  Monterey  County  Office 

of  Education 

6d.  Address  Line  1 . :  901  Blanco  Circle 

6d.  Address  Line  2 . : 

6e.  City . :  Salinas 

6f.  State . ;  Ca 

6g.  Zip/Code . :  93912 

6h.*  Voice  Phone . :  408-755-0308 

6i.*  Electronic  Mailbox....:  mottmar@mcoe.monterey.kl2.ca.us 


7. 

7a. 

TECHNICAL  AND  ZONE  CONTACT 

NIChandle  (if  known) . . : 

7b. 

Whole  Name . : 

Michael  Mellon 

7c. 

Organization  Name . : 

Monterey  County  Office  of 
Education 

7d. 

7d. 

Address  Line  1 . : 

Address  Line  2 . : 

901  Blanco  Circle 

7e. 

City. . . : 

Salinas 

If. 

State . : 

Ca 

7g. 

Zip/Code . : 

93912 

7h.*  Voice  Phone . :  408-755-0383 

7i.*  Electronic  Mailbox....:  mmellon@mcoe.monterey.kl2.ca.us 

FILL  OUT  QUESTION  8  AND  9  FOR  DELEGATIONS  ONLY  (i.e  those 
organizations  running  nameservers  for  a  branch  of  the 
US  Domain  namespace,  for  example:  kl2 .<state>.us) . 


8.  PRIMARY  SERVER:  HOSTNAME,  NETADDRESS 


8a.  NIChandle  (if  known)..: 

8b.  Whole  Name . : 

8c.  Organization  Name . : 

8d.  Address  Line  1 . : 

8d.  Address  Line  2 . : 

8e.  City . : 

8f .  State . : 

8g.  Zip/Code . : 

8h.*  Voice  Phone . : 

8i.*  Electronic  Mailbox....: 

8  j  .  Hostname . : 

8k.*  IP  Address  . : 

81.*  HARDWARE . : 

8m.*  OPERATING  SYS . : 


Michael  Mellon 

Monterey  County  Office  of 

Education 

901  Blanco  Circle 

Salinas 

Ca 

93912 

408-755-0383 

mmellon@mcoe.monterey.kl2 . ca.us 
bill .monterey . kl2 .ca.us 
205.155.43.2 
Sun 

Solaris  2.4 
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9.  *  SECONDARY  SERVER:  HOSTNAME,  NETADDRESS 
9a.*  Hostname . :  morris.ucsc.edu 


9b.*  IP  Address... 

9c.*  HARDWARE . 

9d.*  OPERATING  SYS 


128.114.1.6 

Sun 

SunOS  4 . 1 . 3u 
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APPENDIX  N.  REGISTERING  FOR  AN  AUTONOMOUS  SYSTEM  NUMBER 


Chapter  VI  discussed  the  requirement  for  Autonomous  System  (AS)  registration 
with  the  InterNIC.  Monterey  BayNet  is  has  not  implemented  any  gateways  and  is  not 
required  to  register  as  an  AS  at  this  time.  Excerpts  from  the  registration  template  are 
presented  here  for  reference.  The  Universal  Resource  Locator  (URL)  for  the  latest  copy 
of  this  registration  template  is  ftp://rs.intemic.net/templates/asn-template.txt 

[  netinfo/asn-template . txt  ]  [  09/94  ] 

Registering  for  an  Autonomous  System  Number  implies  that  you 
plan  to  implement  one  or  more  gateways  and  use  them  to 
connect  networks  in  the  Internet.  Please  provide  us  with 
further  details  about  your  plans,  and  with  information  about 
the  administrative  authority  you  have  for  participating  in 
the  Internet. 

It  is  strongly  advised  that  you  follow  the  development  of 
inter- autonomous  systems  protocols  in  the  lAB  task  forces . 

To  obtain  an  Autonomous  System  Number  the  following 
information  must  be  provided: 

1)  The  name,  title,  mailing  address,  phone  number,  and 
organization  of  the  administrative  head  of  the  organization. 

2)  The  name,  title,  mailing  address,  phone  number,  and 
organization  of  the  technical  contact. 

3)  The  name  of  the  autonomous  system  (up  to  12  characters). 
This  is  the  name  that  will  be  used  in  tables  and  lists 
associating  autonomous  systems  and  numbers. 

4)  A  description  of  the  gateway  that  implements  the  inter- 
autonomous  system  protocol  for  interaction  with  other 
autonomous  systems .  Currently  the  exterior  gateway  protocol 
(EGP)  is  being  used  for  this  purpose  (RFC  904) .  This 
gateway  should  comply  with  RFC  1009,  Requirements  for 
Internet  Gateways . 

5)  A  description  of  the  gateway  hardware,  including  CPU  and 
interfaces . 
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6)  A  description  of  the  gateway  software,  including 
operating  system  and  languages . 

7)  The  deployment  schedule  for  the  autonomous  system. 

(a)  initially, 

(b)  within  one  year, 

(c)  two  years,  and 

(d)  five  years. 

8)  What  networks  will  be  interconnected  by  these  gateways? 
What  are  the  internet  addresses  of  each  gateway? 

RECOMMENDED  READING  (From  Registration  Services) 

Mills,  D.L.  Exterior  Gateway  Protocol  Formal  Specification. 
1984  April;  RFC  904.  30  p.  {RS.INTERNIC.NET  POLICY 

RFC904.TXT) . 

Braden,  R.T.;  Postel,  J.B.  Requirements  for  Internet 
Gateways.  1987  June;  RFC  1009.  55  p.  (RS.INTERNIC.NET 

POLICY  RFC1009.TXT) . 
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APPENDIX  O.  MACTCP  CONFIGURATION 


MacTCP  is  the  proprietary  software  being  used  in  Monterey  BayNet  to  allow  Macintosh 
products  to  "talk"  Internet  Protocol  (IP).  The  easiest  way  to  to  obtain  MacTCP  is 
through  the  purchase  of  The  Internet  Starter  Kit  for  the  Macintosh  (currently  $29.95)  at 
many  bookstores  [Engst,  94].  Version  2.0.6  comes  bundled  with  operating  system  7.5.  A 
version  2.0.4  upgrade  to  2.0.6  "patch"  is  available  at  ftp://seeding.apple.com/mactcp/. 
Monterey  BayNet  recommends  using  the  MacTCP  version  that  came  bundled  with  system 
7.5  or  version  2.0.4.  The  "patched"  version  2.0.6  is  NOT  recommended  because  it  has 
been  found  to  cause  more  errors  than  it  fixes. 

To  Install  MacTCP  drag  the  MacTCP  icon  onto  the  system  folder.  Open  MacTCP  and 
immediately  click  on  the  "More..."  button  to  expose  the  screen  below. 

Configure  as  below  substituting  appropriate  IP  addresses: 

Monterey  Domain  Name/IP  Address=  nionterey.kl2.ca.us  205.155.43.2 
Santa  Cruz  Domain  Name/IP  Address  =  santacruz.kl2.ca.us  205.155.8.2 
Gateway  is  the  site  router  address  -  205.155.y.l 

In  the  IP  Address  box  change  only  the  class  do  not  attempt  to  modify  the  net,  subnet  or 
node.  When  complete  click  OK  to  bring  back  the  opening  screen. 


. Obtain  Address:  — 

(§)  Manually 
O  Seruer 
O  Dynamically 


Routing  Information: 

Gateway  Address: 


205.155.34.1 


I  OK  I  [  Cancel  ] 


— . . IP  Address: . — . 

Class:rc~1  Address:  205.155.34.3 
Subnet  Mask:  255.255.255.0 


MMIMMI 


Net  I  Subnet  I  Node 
Dits:  24  0  8 


Net:  □  Lock 

Subnet:  jo  1  □  Lock 

□  Lock 


Node: 


— Domain  Name  Server  Information: — 

Domain  iP  Address  Defauit 


monterey.k12.ca.us  |  [205.155.43.2 


]  ® 
1  o 


Input  the  IP  address  of  the  specific  machine  you  are  configuring.  A  good  practice  is  to 
write  the  IP  address  and  name  of  the  terminal  on  the  face  of  the  terminal.  This  will  avoid 
future  confusion  if  the  settings  of  MacTCP  are  lost.  Select  Ethernet  by  clicking  on  it. 


Close  MacTCP.  You  will  be  advised  to  restart  the  machine  in  order  for  the  changes  to 
take  effect.  Before  restarting  verify  that  AppleTalk  is  active  in  the  Chooser  by  selecting 
"active"  as  shown  below. 
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Verify  that  EtherTalk  is  selected  in  the  Network  control  panel.  The  Macintosh  is  now 
configured  for  proper  operation  in  future  sessions.  Restart  your  Macintosh,  test  and 
enjoy! 
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APPENDIX  P.  WINDOWS  TRUMPET  WINSOCK  PACKET  DRIVER 

CONFIGURATION 


Install  Trumpet  Winsock  as  a  packet  driver  in  accordance  with  the  install.txt  file  provided 
with  the  software.  Trumpet  Winsock  can  be  obtained  at  the  following  URL: 
ftp://ftp.cica.indiam.edu/ftp/pub/pc/win3/winsock/twsk20b.zip. 


The  following  configuration  parameters  have  been  tested  in  Monterey  BayNet  sites: 

IP  address:  The  IP  address  of  the  machine.  (205. 155. y.  1  and  205. 155.y.2  are  the  router 
and  WWW  server.  205. 155.y.3  is  the  first  terminal  at  the  site,  205. 155.y.254  the  last).  It  is 
good  practice  to  write  the  IP  address  on  the  face  of  the  device. 

Netmask:  255.255.255.0 

Default  Gateway:  The  site  router  IP  address.  205.155.y.l 
Name  server:  Monterey  =205.155.43.2 
Santa  Cruz  =  205.155.8.2 
Domain  suffix:  Monterey  =  monterey.kl2.ca.us 
Santa  Cruz  =  scruz.kl2.ca.us 

Packet  Vector:  Deftiult  value  of  00.  The  value  must  reflect  the  packet  driver  vector 
where  the  packet  driver  is  installed.  The  number  is  expressed  in  hexadecimal  without  the 
leading  "Ox". 


MTU:  1500  is  maximum  and  recommended. 

TCP  RWIN:  Defaults  to  4096  but  can  be  larger. 

TCP  MSS:  Use  the  defeult  of  1460. 

The  Internal  SLIP  and  PPP  check  boxes  should  NOT  be  checked. 


Network  Configuration 


IP  address 
Netmask 
Name  server 
Domain  Suffix 
Packet  vector 


205.155.33.7 


255.255.255.0 


205.155.43.2 


Default  Gateway 
Time  server 


205.155.33.1 


monterey.kl  2.ca.us 


00 


MTU 


Demand  Load  Timeout  (secs) 


1500 


TCP  RWIN 


4096  h-CPMSS 


TCP  RTO  MAX 


1460 


D  Internal  SUP  G  Internal  PPP 

Online  Status  Detection 

SUP  Port 

®  Mum 

Baud  Rate 

O  DCD  |RLSD|  checfe 

d  Hnrdwaf^  Haisdsliisfe 

O  DSR  check 

IZl  Van  Jacobsc 

m  CSUP  compression 

APPENDIX  Q.  ACRONYMS 


ADN 

Advanced  Digital  Network 

AIF 

Audio  Interchange  Format 

ANSI 

American  National  Standards  Institute 

ATM 

Asynchronous  Transfer  Mode 

AU 

Audio  (file  name  extension) 

AUI 

Attachment  Unit  Interface 

BMP 

Bitmap  Picture  (file  name  extension) 

BRI 

Basic  Rate  Interface 

CalREN 

California  Research  and  Education  Network 

CIR 

Committed  Information  Rate 

CNE 

Certified  NetWare  Engineer 

COE 

County  OflSce  of  Education 

CSMA/CD 

Carrier  Sense  Multiple  Access/with  Collision  Detection 

csu 

Channel  Service  Unit 

CTS 

Clear  To  Send 

DLCI 

Data  Link  Control  Identifier 

DLL 

Dynamic  Link  Library 

DoD 

Department  of  Defense 

DoN 

Department  of  the  Navy 

DS 

Data  Send 

DSU 

Digital  Service  Unit 

EIA 

Electronic  Industries  Association 

.EXE 

Executable  (file  name  extension) 

FDDI 

Fiber  Distributed  Data  Interface 

FTP 

File  Transfer  Protocol 

Gb 

Gigabit 

GB 

Gigab)de 

GIF 

Graphics  Interchange  Format  (file  name  extension) 

GUI 

Graphical  User  Interface 

•gz 

Gzip  compressed  file  (file  name  extension) 

HiCap 

Hi^  Capacity  Digital  Service 

.HQX 

BinHexed  (file  name  extension) 

HTML 

HyperText  Markup  Language 

HTTP 

HyperText  Transport  Protocol 

Ula 

Initiative  for  Information  Infrastructure  and  Linkage  Applications 

IEEE 

Institute  of  Electrical  and  Electronics  Engineers 

IETF 

Internet  Engineering  Task  Force 

IGP 

Interior  Gateway  Protocol 

IGRP 

Interior  Gateway  Routing  Protocol 

IMAP 

Internet  Message  Access  Protocol 

IP 

Internet  Protocol 
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IPX  Internetwork  Packet  exchange 

ISDN  Integrated  Services  Digital  Network 

JFff  JPEG  File  Interchange  Format 

JPEG  Joint  Photographic  Experts  Group 

K-12  Kindergarten  through  12th  Grade 

KB  Kilobyte 

KBPS  Kilobits  Per  Second 

LAN  Local  Area  Network 

LATA  Local  Access  Transport  Area 

LED  Light-Emitting  Diode 

LMI  Local  Management  Interface 

LZW  Lempel-Ziv-Walsh 

MAC  Medium  Access  Control 

.MAC  MacPaint  (file  name  extension) 

MAOS  Monterey  Academy  of  Oceanographic  Science 

MBARI  Monterey  Bay  Aquarium  Research  Institute 

MBone  Multicast  Backbone 

Mbps  Megabits  per  second 

MB  ReEF  Monterey  Bay  Regional  Education  Futures 
MB  TEC  Monterey  Bay  Technology  Education  Center 

MCOE  Monterey  County  Office  of  Education 

MPEG  Moving  Picture  Experts  Group 

MPOE  Minimum  Point  of  Entry 

NCC  Network  Control  Center 

NCSA  National  Center  for  Supercomputing  Applications 

NESC  National  Electrical  Safety  Code 

NIC  Network  Information  Center  /  Network  Interface  Card 

Nil  National  Information  Infi-astructure 

NIU  Network  Interface  Unit 

NNTP  Network  News  Transfer  Protocol 

NOAA  National  Oceanic  and  Atmospheric  Administration 

NOC  Network  Operations  Center 

NPS  Naval  Postgraduate  School 

NRC  National  Research  Council 

OSPF  Open  Shortest  Path  First 

.PDF  Printer  Description  File  (file  name  extension) 

PICT  Picture  file 

POP  Post  Office  Protocol 

PPP  Point-to-Point  Protocol 

PRI  Primary  Rate  Interface 

.PS  PostScript  f(file  name  extension) 

PVC  Permanent  Virtual  Circuit 

REINAS  Real-Time  Environmental  Information  Network  and  Analysis  System 
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RFC 

Request  For  Comments  (See  bibliography) 

RIP 

Routing  Information  Protocol 

RJ 

Registered  Jack 

RLE 

Run  Length  Encoded 

SCCOE 

Santa  Cruz  County  Office  of  Education 

SFSU 

San  Francisco  State  University 

SGML 

Standard  Generalized  Markup  Language 

SPF 

Shortest  Path  First 

■tar 

Tape  ARchive  (file  name  extension) 

•tar.Z 

Compressed  Tape  ARchived  file  (file  name  extension) 

TA 

Terminal  Adapter 

TCP/IP 

Transmission  Control  Protocol/Intemet  Protocol 

TD 

Transmit  Data 

TIA 

Telecommunications  Industry  Association 

TSU 

T1  Service  Unit  (Adtran) 

T-1 

Carrier  bandwidth  of  1.544  Mbps  (2.048  Mbps  in  Europe) 

ucsc 

University  of  California  Santa  Cruz 

UPS 

Uninterruptible  Power  Supply 

URL 

Uniform  Resource  Locator 

UTP 

Unshielded  Twisted-Pair 

UU 

Uuencode/Uudecode 

WWW 

World-Wide  Web 

.z 

Packed  file  (file  name  extension) 

Z 

Compressed  file  (file  name  extension) 

ZIP 

Compressed  File  (file  name  extension) 
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49.  LT  Cody  Horton,  USN  . 1 

Fleet  Numerical  Meteorology  and  Oceanography  Center  (FNMOC) 

7  Grace  Hopper  Ave,  Stop  1 
Monterey,  C^ifomia  93943-5501 
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Santa  Cruz,  California  95064 

81.  Chris  Taylor . 1 


Director  of  Computing  and  Computer  Resources  (CCR) 
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